A0-AU9  322 


NAVAL  POSTMAOOATf  SCHOOL  MONTH*  T  CA 
A  MIJH  AC SOLUTION  AMMUNITION  ACS UPNLV  MOOCL. (U> 
MAA  M  M  BUCHA*  T  J  MCOAAMN 


ft%  S/l 

ML 


UNCLASSIFIED 


MIC  FILE  COPY  /ID  All  9322 


NAVAL  POSTGRADUATE  SCHOOL 


Monterey,  California 


A  HIGH  RESOLUTION 


AMMUNITION  RESUPPLY  MODEL 
by 

Peter  J.  Bucha 
and 

Thomas  J .  McGrann 
March  1982 

S.H.  Parry 

Thesis  Co-Advisors:  J.K.  Hartman 

Approved  for  public  release:  distribution  unlimited 


-  »•*  'i 


_ Unclassified - 

StCUIMTv  classification  of  this  MSI  f»w»  Dm*  CNI *rW> 


REPOST  DOCUMENTATION  PACE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

'  MfOUT  NUtfllf  1.  OOVT  teetUMN  MO. 

fib -At #32  ? 

»  ACCIflCMT‘4  CATALOG  NUMMCM 

4.  TlTLt  i 'mH  Mtttf) 

A  HIGH  RESOLUTION  AMMUNITION 

RESUPPLY  MODEL 

*  TYPE  OF  *EFO»T  A  Pf  ftfOO  COVCftfO 

Master's  Thesis 

March  1982 

4.  f CNfORMIMO  OAG  ACfOAT  SUMAC A 

7.  tutHOA’aj 

Peter  J.  Bucha 

Thomas  J .  McGrann 

t.  tONTAACT  OA  9AAMT  ngmA^Akj 

»  ACNfONMINO  OAOANIZATION  NAMC  4M0  AOORCIS 

Naval  Postgraduate  School 

Monterey,  California  93940 

18.  AAOOAAM  CLCMCNT  ANQjCCT  Till 
AACA  4  MONK  UNIT  MUMOCAt 

<1  COMTaOLLIMO  Office  NAMC  AMO  AOOMCII 

Naval  Postgraduate  School 

Monterey,  California  93940 

12  PtPOPT  OATS 

M  awh  19.8  2 

I*,  mumbcr  of  paqcs 

268 

Tl  '  M^MiTo*iM<i  AOCMCV  MAMC  4  AOOACSSCII  «Nmu  Hmm  CwmllM «  Ollfeo 

18.  SCCUAITV  CLASS,  fml  Ml*  rtt.m 

Unclassified 

IE*.  OMCL  AtElFlC  ATlON/ OOVNORAOinC 
SCHEDULE 

IS.  CNSTNltuTlON  STATCMCNT  (ml  INI*  A***) 

Approved  for  public  release:  distribution  unlimited 

17.  OISTNiailTtON  STATCMCNT  Cal  t*a  akairaaf  Im  Ofaa*  J*,  II  flMnal  Ma  Ca»aM> 

IS  SUf*CCMCMTANV  MOTCS 

IS.  ACT  MONOS  CCaMitana  a*  raaaraa  alMa  II  aaaaaaa^  anf  IMMNIf  Sr  **••*  **■••») 

Simulation  Logistics  Simulation 

Combat  Model  Ammunition  Simulation 

STAR  Model 

_ 

SO.  SkaitSUT  ccmnaaa  m  ravaraa  MA*  II  aaa«aaa»»  aaA  INwMIf  Sr  MaaO  ■alii) 

This  thesis  presents  a  computer  simulated  model  of  ammunition 
resupply  in  a  U.S.  combat  battalion,  The  model  is  based  on 
current  ammunition  resupply  doctrine  and  has  been  designed  as 
a  stand-alone  simulation,  Additionally,  this  model  has  been 
structured  to  parrallel  the  Simulation  of  Tactical  Alternative 
Responses  CSTAR)  model  so  that  future  enhancements  might  include 
its  full  integration  into  the  STAR  model,  When  an  integration 

- - - — - 4 - 

DO  ,:s"n  1473 


COITION  Of  I  MOV  ••  It  OOSOLCTC 
S/N  OIOJ-4I4-4SOI  I 


sccurity  CLASstficiTTioVos  Twit  paSS  coraa  BSTKiwm) 


1 


Encpnnmii  jeananEnis 


#20  -  ABSTRACT  -  CONTINUED 

is  accomplished,  the  important  dimension  of  combat  service 
support  will  become  an  influencing  factor  in  the  decision 
making  process  at  all  levels  of  the  combat  model. 


2 


DO  Form  14*3 
syil  oV&2-ni4-«6oi 


,  .Unrlassi f lad  i 

lieUMfV  CbAMIftC*TI«N  •*  TUI* 


8m  |MH« 


Approved  for  public  release:  distribution  unlimited 


A  High  Resolution  Ammunition  Resupply  Model 


by 


Peter  J.  Bucha 
Captain,  United  States  Army 
B.S., United  States  Military  Academy,  1972 

and 

Thomas  J.  McGrann 
Captain,  United  States  Army 
B.S., United  States  Military  Academy,  1972 

Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  OPERATIONS  RESEARCH 


from  the 

NAVAL  POSTGRADUATE  SCHOOL 
March,  1982 


Authors: 


Approved  by: 


3 


ABSTRACT 


This  thesis  presents  a  computer  simulated  model  of 
ammunition  resupply  in  a  O.S.  combat  battalion.  The  model 
is  based  on  current  ammunition  resupply  doctrine  and  has 
been  designed  as  a  stand-alone  simulation.  Additionally, 
this  model  has  been  structured  to  parallel  the  Simulation  of 
Tactical  Alternative  Responses  (STAB)  model  so  that  future 
enhancements  might  include  its  full  integration  into  the 
STAR  model,  flhen  such  an  integration  is  accomplished,  the 
important  dimension  of  combat  service  support  will  become  an 
influencing  factor  in  the  decision  making  process  at  all 
levels  of  the  combat  model. 
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I.  inieodociion 


A.  GENERAL 

Coabat  is  a  complex,  multi-dimensional  process,  the 
nature  of  which  defies  siaple  description.  In  its  broadest 
sense,  this  process  is  divided  into  land,  sea,  and  air 
categories.  The  Army,  for  its  part,  focusing  its  attention 
on  the  air/land  battle,  subdivides  the  process  further  into 
Coabat,  Coabat  Support,  and  Coabat  Service  Support 
functions.  While  it  is  generally  recognized  that  a  total 
picture  of  coabat  cannot  be  gained  by  looking  at  any  single 
subdivision  of  the  process,  this  segmentation  overlays  a 
conceptual  framework  that  brings  with  it  a  degree  of  clarity 
necessary  for  analysis  purposes. 

Coaputer  siaulaticns  aodelling  the  air/land  battle  have 
naturally  evolved  along  these  segmented  paths.  They  have, 
however,  become  so  functionalized  that  they  exist  today  as 
parallel  and  completely  separate  worlds  seeking  to  model  the 
same  phenomenon.  The  degree  to  which  this  segmentation  has 
developed  was  a  natural  conseguence  both  of  hardware 
limitations  imposed  by  older  generation  computers,  and  by 
the  very  complexity  of  the  coabat  process  itself. 
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Modellers,  in  attempting  to  present  a  ’'total'1  picture  of 
combat,  hare  erected  bridges  between  these  paths  with 
varying  degrees  of  success.  These  bridges  generally  take 
the  fora  of  a  Lanchester  equation.  In  practice,  a  modeller 
concentrates  on  one  path  seeking  resolution  while  portraying 
necessary  parallel  processes  in  this  simplified  mathematical 
form.  This  technique  permits  the  modeller  to  capture  at 
least  some  measure  of  the  interaction  of  these  paths  on 
battle  outcome,  without  necessitating  the  use  of  an 
unrealistic  amount  of  computer  time. 

The  direct  consequence  of  this  situation  is  that  while 
usually  answering  questions  directed  at  some  particular 
segment,  and  amply  answering  the  questions  of  who,  what,  and 
when  at  the  interface  points  between  paths,  such  models  do 
not  achieve  the  sharpened  focus  needed  to  answer  the  where, 
how,  and  why  of  the  total  process.  Perhaps  this  last  set  of 
questions  is  avoided  because  the  answer  to  them  requires 
modelling  command  logic  and  synergistic  interplay  difficult 
to  capture  and  quite  conceivably  beyond  the  scope  of  any  one 
model's  charter.  At  any  rate,  the  loss  of  this  detail 
prevents  one  from  really  answering  basic  questions  as  to  the 
effectiveness  and  workability  of  the  combined  "total" 
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process.  In  essence,  the  fundamental  question,  "Can  it  be 
done?",  is  never  adequately  answered. 

B.  LOGISTICS  MODELS 

Current  logistics  models  then,  although  running  the 
gamut  from  high  level,  high  resolution  simulations  to  low 
level,  low  resolution  simulations,  must  be  characterized,  in 
accordance  with  the  above  arguments,  as  single  dimensional 
models.  For,  operating  independently  of  any  combat  model, 
logistics  models  must  generate  the  demands  they  respond  to 
in  some  "artificial"  way  either  externally  >r  internally. 
Externally,  data  generated  from  a  combat  model  is  converted 
to  some  record  of  expenditures  and  front-ended  into  the 
model  as  a  sequence  of  events.  Internally,  the  combat 
process  is  expressed  by  some  form  of  Lanchester  equation 
which  dynamically  generates  specific  requirements  within  the 
context  of  the  model  itself.  Output  from  these  models  is 
then  designed  to  provide  a  record  of  activities  completed 
over  time  as  a  measurement  of  an  organization's  ability  to 
respond  to  a  varied  requirements  load.  Logistics 
effectiveness  is  then  examined  in  aggregated  terms,  such  as 
tons  delivered  per  day,  or  miles  travelled  per  day.  Details 
of  interplay  between  the  combat  and  logistical  processes  are 
generally  not  available. 


16 


7ith  the  develops ent  of  the  Simulation  of  Tactical 
Alternative  Responses  (STAR)  model  at  the  Naval  Postgraduate 
School  (NPS) ,  logisticians  have  been  given  a  unique 
opportunity  to  investigate  this  dynamic  interaction  between 
combat  and  logistical  processes  at  the  most  critical 
juncture,  th9  battlefield.  Since  its  initial  coding  in  1978, 
the  model  has  been  continually  expanded  to  include  an  ever 
widening  horizon  of  combat  functions.  Several  preliminary 
attempts  have  been  made  to  integrate  logistics  into  the 
model,  but  as  yet,  little  logistics  is  played. 

C.  THESIS  OBJECTIVES 

In  light  of  the  above  considerations,  a  goal  of 
developing  a  rudimentary  high  resolution  logistics  module 
was  established,  with  the  ultimate  aim  of  the  project  being 
its  eventual  integration  into  the  STAR  model.  After  some 
consideration,  the  project's  goal  was  redefined  further  and 
effort  was  centered  on  the  development  of  an  ammunition 
(Class  V)  model  within  a  combat  battalion.  Ammunition  was 
chosen  both  because  of  its  critical  impact  on  the 
battlefield  and  because  the  logic  developed  for  this  class 
of  supply  could  easily  be  expanded  to  other  classes.  Such 
an  attempt  would  represent  at  least  a  first  step  toward 


captaring  the  subtle  interaction  between  the  coabat  and 
logistical  processes.  The  project’s  plannd  approach  was  to 
have  included: 

•  A  review  of  previous  work  done  at  HPS  in  the  area  of 
resupply. 

•  A  review  of  of  existing  aaounition  resupply  aodels 
currently  in  use  within  the  Army  coaaunity. 

•  Paailiarization  with  the  workings  of  the  STAR  aodel  with 
the  objective  of  identifying  the  logical  interface 
points  for  a  logistics  nodule. 

•  The  design  of  an  aaaunition  resupply  aodel  written  in 
SIMSCRIPT  11.5  that  siaulates  the  resupply  process 
within  a  coabat  battalion. 

•  Integration  of  this  logistics  aodel  into  STAR  at  the 
appropriate  points  so  that  STAR  generated  data  such  as 
aaaunition  expended,  vehicles  killed,  et  cetera,  would 
provide  a  driver  for  the  logistics  nodule. 

•  Incorporation  of  the  anforaation  provided  by  the 
logistics  aodule  into  the  coapany  and  battalion 
coaaander  decision  logic  of  the  STAR  aodel. 

Preliainary  forays  into  the  organization,  use,  and 

operational  vicissitudes  of  the  STAR  aodel,  however. 
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immediately  identified  and  underscored  the  priaary 
disjuncture  between  combat  and  service  support  models  to  be 
pace  of  battle.  The  plain  fact  is  that  the  critical  time 
window  for  analysis  of  operational  effectiveness  is 
different  for  the  two  types  of  models.  High  resolution 
combat  models  generally  focus  on  the  inner  workings  of  a 
battle  that  may  last  less  than  four  hours,  logistics 
models,  in  contrast,  operate  over  tiae  spans  ranging  from 
three  to  thirty  days.  In  the  current  STAR  model,  battles 
generally  terminate  after  three  hours,  well  before  the 
logistical  network  is  even  alerted  for  action.  Planned 
expansion  of  the  STAR  model  beyond  the  brigade  battle  now 
fought,  however,  makes  the  eventual  inclusion  of  logistical 
factors  both  possible  and  necessary. 

With  these  considerations  in  mind,  the  initial 
objectives  of  interfacing  directly  with  the  STAR  model  was 
modified  and  the  planned  logistics  module  was  expanded  to  a 
full  stand-alone,  high  resolution  model.  Supplementary 
objectives  were  established  in  order  to  achieve  the 
completeness  of  a  stand-alone  model  while  keeping  the 
ultimate  objective  of  eventual  interface  with  STAB  in  sight. 
These  additional  objectives  were: 
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•  Development  of  a  detailed  model  that  responds  to 
requests  for  ammunition  resupply,  maintains  a  simplified 
stockage  system,  and  models  the  movement  cf  rounds  down 
to  the  individual  weapon. 

•  Maintenance  of  an  appropriate  level  of  resolution  within 
the  model.  Eventual  integration  into  the  STAB  model 
dictates  that  the  resupply  process  must  begin  with  and 
be  based  on  k.  owledge  of  expenditures  of  a  variety  of 
ammunitions  fired  by  any  number  of  individual  systems. 

•  Maintenance  of  a  high  degree  of  flexibility  within  the 
model.  The  model  designed  must  be  flexible  enough  to 
adapt  to  the  wide  variety  of  tables  of  organization  and 
equipment  that  night  be  played  in  STAB. 

D.  THESIS  ORGANIZATION 

Chapter  II  provides  an  overview  of  the  background 
research  which  went  into  the  formation  of  this  model.  It 
includes  a  brief  outline  of  current  Army  ammunition  resupply 
doctrine,  an  overview  of  two  of  the  most  current  Army 
models,  and  an  examination  of  several  past  logistics  theses 
done  at  the  Naval  Postgraduate  School. 

Chapter  III  presents  the  Logistics  Model  which  is  the 
primary  focus  of  this  thesis.  It  provides  an  overview  of 
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model  functions  and  explains  the  major  model  assumptions. 
Topics  discussed  include:  the  battle  scenario,  requests  for 
resupply,  the  distribution  of  resupply  assets,  and  the 
redistribution  of  on-hand  assets. 

Chapter  17  discusses  lessons  learned  in  the  construction 
of  the  model  and  outlines  future  areas  of  consideration  for 
model  enhancement. 

appendix  A  provides  an  expanded  explanation  of  the 
material  mentioned  in  Chapter  III.  This  section,  however, 
presents  the  material  in  a  fora  suitable  for  the  reader  who 
is  familiar  with  both  combat  modelling  techniques  and 
SIHSCRIPT  II. 5. 

Appendix  B  is  a  detailed  explanation  of  the  model  code 
itself.  It  provides  the  reader  with  definitions  of  all 
entities,  sets,  attributes,  and  variables  used  in  the  model, 
along  with  a  listing  and  line  by  line  explanation  of  the 
computer  code  written. 
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II .  STATE  OF  THE  ABT 


A.  INTBOPOCTION 

This  chapter  presents  an  overview  of  the  background 
research  that  influenced  the  formation  of  the  aaaunition 
resupply  aodel.  This  inforaatian  is  provided  both  as  a 
ready  reference  for  the  works  investigated  and  as  a  means  of 
explaining  the  underlying  rationale  of  many  of  the  concepts 
later  adopted  for  use  in  the  aodel.  This  chapter  includes: 
a  brief  explanation  of  the  current  and  future  Aray  doctrine 
regarding  aaaunition  resupply;  a  discussion  of  two  of  the 
Aray's  aost  up  to  date  aaaunition  resupply  models,  HELAPS 
II,  and  ABB;  and  an  in  depth  look  at  past  logistics  thesis 
efforts  pertinent  to  this  aodel. 

B.  AMBONITION  SOPPOBT  IN  TODAY'S  ABBI 

Without  sufficient  aaaunition  resources  a  coabat  unit's 
effectiveness  is  degraded  and  the  tactical  alternatives 
available  to  its  leaders  severely  restricted.  For  this 
reason,  a  procedure,  which  first  seeks  an  internal  solution 
through  the  redistribution  of  assets,  and  then  an  external 
solution  through  resupply,  is  standard  regardless  of  unit 
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type.  For  example,  at  platoon  or  company  level  the 
redistribution  of  on-hand  aaaunition  assets  is  standard 
operating  procedure  at  the  conclusion  of  any  move, 
regardless  if  the  aove  is  offensive  or  defensive. 

when  aaaunition  becoaes  a  dwindling  resource  on  a  weapon 
the  platoon  leader  is  notified,  regardless  if  the  weapon  is 
an  M-16  or  the  aain  gun  of  an  HI  tank.  The  platoon  leader 
then  takes  appropriate  action  either  by  redistributing  his 
own  platoon  resources  or  requesting  resupply  froa  the 
coapary  coaaander,  or  both.  In  a  similar  fashion,  platoon 
shortages  are  examined  at  the  ccap&ny  level  and  if  necessary 
a  resupply  request  is  submitted  to  battalion.  At  battalion, 
a  support  platoon  receives  requests  for  resupply  froa  the 
company  then  issues  aaaunition  froa  the  battalion's  assets. 
This  support  platoon  in  turn  replenishes  its  stocks  froa 
either  the  brigade  aaaunition  transfer  point  (ATP)  or  the 
division  aaaunition  supply  point  (ASP) .  The  ATP  and  ASP  in 
turn  are  supported  by  a  corps  storage  area  (CSA) .  A  graphic 
representation  of  a  divisional  aaaunition  support  structure 
is  given  in  Figure  1. 

The  logic  that  dictates  the  resupply  activity  which 
should  take  place  and  where  it  should  take  place  is  the 
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CSA  -  Corps  Support  Area 

ASP  -  Ammunition  Supply  Point 

ATP  -  Ammunition  Transfer  Point 


Figure  1:  Ammunition  Support  Structure 


objective  of  this  eodel.  Determination  of  the  correct 
course  of  logistic  action  at  each  level  of  control  froa  the 
individual  weapon  up  is  a  function  of  how  auch  is  known 
about  the  situation  at  any  tiae.  This  knowledge  is 
adaittedly  iaperfect  due  to  tiae  delays,  huaan  error,  and 
the  stress  of  battle.  To  capture  the  essence  of  this 
iaperfect  information  flow,  a  central  concept.  Level  of  Need 
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(LON) ,  was  developed  to  nark  thresholds  for  different 
activities.  This  concept  is  explained  in  detail  in  Chapter 
III. 

C.  EXISTING  ARMY  MODELS 

The  purpose  of  this  section  is  to  present  the  reader  an 
overview  of  the  two  most  recently  developed  Aray  ammunition 
resupply  models.  The  two  models  are  the  Human  Engineering 
Laboratory  Ammunition  Point  Simulation  (HELAPS  II)  and  the 
Ammunition  Resupply  Model  (ABM) .  Although  other  ammunition 
resupply  models  exist,  the  two  mentioned  above  depict 
resupply  at  a  level  and  degree  of  resolution  that  directly 
relates  to  this  thesis.  The  purpose,  characteristics, 
assumptions,  input,  output,  strengths,  and  weaknesses  of 
each  model  are  discussed  to  provide  an  overview  of  the 
ammunition  resupply  modelling  capabilities  that  are 
available  today.  The  information  presented  in  this  chapter 
has  been  extracted  from  the  referenced  literature  regarding 
the  respective  model. 

1.  HEMil-II 

The  initial  model  for  discussion  is  the  HELAPS  II 
model.  This  model  was  developed  by  Armament  systems  Inc., 
Anaheim,  Calif.,  under  contract  to  the  OS  Aray  Missle  and 
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Munitions  Center  and  School,  Directorate  of  Combat 
Develo pnen ts ,  Redstone  Arsenal,  Alabama.  HELAPS  II  is  a 
stochastic,  event  sequenced  simulation  that  is  run  on  a  CDC 
6000  series  machine  with  GASP  17  simulation  language.  The 
model  simulates  the  internal  operation  of  an  ammunition 
resupply  activity  (CSA/ASP/ATP)  to  include  the 
transportation  system  connecting  the  resupply  point  with  its 
source  of  supply  and  its  customers.  The  model  constrains 
the  flow  of  munitions  through  realistic  delays  representing 
the  limited  capability  of  material  handling  equipment  (MHE)  , 
resupply  vehicles  (RSV's)  and  personnel  operating  in  an 
environment  susceptible  to  delays  due  to  distance,  time, 
weather  conditions,  integrated  battle,  and  limited 
resources.  [Ref.  1] 
a.  Purpose 

The  HELAPS  model  is  meant  to  be  used  as  an 
analysis  tool  for  evaluating  ammunition  resupply  activity 
dynamics,  operational  concepts  development,  TOE 
design/validation  and  mission  area  analysis.  HELAPS  II  does 
this  by  simulating  the  movement  of  resupply  vehicles  (BSV‘s) 
from  the  customer  or  source  element  through  the 
inprocessing,  loading/off-loading  operations,  outprocessing 
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activities,  and  then  back  to  their  hone  elements.  These 
activities  all  occur  based  on  a  workload  generated  in  a 
realistic  combat  scenario. 

b.  Characteristics 

The  aodel  uses  a  dynamic,  computer, 
force-on-force  wargame  (ie.  JIFFY)  to  determine  the  interval 
between  resupply  convoys  by  generating  expenditures.  These 
resupply  convoys  of  up  to  15  vehicles  are  constrained  by 
availability  of  vehicles,  distance  traveled,  enemy  attack 
and  environmental  conditions.  When  the  convoy  arrives  at 
the  resupply  point  the  HSV's  are  subject  to  delays  caused  by 
queues,  processing,  HHE/personnel  availability,  stock 
shortages,  enemy  attack  and  environmental  conditions. 
Reliability,  availability  and  maintainability  (RAH)  of 
equipment,  along  with  internal  resupply  activity  policies 
are  also  considered  where  applicable.  Once  all  elements  in  a 
convoy  are  out-processed  the  convoy  returns  to  its  point  of 
departure. 

Throughout  the  running  of  HELAPS  II  information 
is  collected  concerning  personnel  activities  and  equipment 
performance.  This  information  is  analyzed  to  determine  the 
following: 

(1)  HHE/personnel  utilization  and  performance. 
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(2)  Inprocess ing/outprocessing  delays. 

(3)  Capacities  for  receipt  and  issue  of  munitions. 

(4)  Optimal  stockage  objectives. 

(5)  Effects  of  enemy  actions  on  performance  to  include: 

(a)  Physical  layout. 

(b)  Security  requirements. 

(6)  Distribution  of  resupply  turn-around  times. 

(7)  optimal  mix  of  HHE  and  BSV's. 

(8)  Impact  of  BAH  on  mission  performance. 

(9)  Effectiveness  of  operating  procedures. 

(10)  Adequacy  of  current  or  proposed  TOE'S. 

c.  Assumptions 

All  models  make  assumptions  that  play  an 
important  role  in  the  results  generated  and  analysis 
performed.  The  assumptions  made  in  the  HELAPS  II  model  are: 

(1)  Resupply  requirements  for  individual  weapons  are 
consolidated  at  the  firing  unit's  battalion. 

(2)  All  resupply  activities  take  place  on  a  24  hour  basis. 

(3)  Inclement  weather,  night  operations,  and  enemy 
suppression  degrade  performance  of  the  resupply 
acti  vity. 
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d.  Input 

Input  data  needed  to  run  this  simulation 
consists  of  numerous  user  entries.  Soae  examples  of  this 
input  data  are: 

(1)  Distances  between  firing  units  and  resupply 
activities. 

(2)  Distribution  of  ammunition  consumption  by  firing  unit 
for  the  simulation  period. 

(3)  Number  of  personnel  available  by  duty  position  at  the 
resupply  activity. 

(4)  Amount  of  stock  by  type  available  at  the  resupply 
activity. 

(5)  Assignment  of  HHE  to  specific  tasks  at  each  resupply 
acti  vity. 

(6)  Distances  between  inter-activity  elements. 

(7)  A  scenario  of  enemy  activity. 

(8)  All  start ,  stop,  and  pause  times. 

(9)  operating  procedures  for  each  resupply  activity. 

(10)  Environmental  conditions  by  activity. 

(11)  Host  nation  role  if  applicable. 

(12)  Stockage  levels  for  each  ammunition  type. 


29 


e.  output 

This  input  data  will  generate  output  data  of  the 
following  nature: 

(1)  Amount  of  ammunition  received  and  issued  at  a  resupply 
point  by  type. 

(2)  Start  and  stop  stockage  levels  by  ammunition  type. 

(3)  Discrete  and  average  turn-around  tiaes  by  BSV/convoy. 

(4)  Discrete  and  average  processing  tiaes  both  in  and  out 
of  the  resupply  point  by  HSV/convoy. 

(5)  Discrete  and  average  nonavailability  tiaes  by 
equipaent  type. 

f.  Strengths 

The  major  strengths  of  HBLAPS  II  are  its  ability 
to  accomplish  the  following: 

(1)  Provide  a  tool  to  analyze  the  internal  operations  of  a 
munitions  resupply  activity  at  any  level. 

(2)  Provide  inferences  as  to  the  total  issue  capability  of 
a  designated  TOE. 

(3)  Collect  data  on  the  number  of  BSV's  and  convoys 
required  to  support  a  unit  in  a  given  scenario. 

(4)  Provide  refined  estiaates  (ie.  Bean  and  statistical 
distribution)  of  the  tiae  required  for  an  RSV  or 
convoy  to  resupply  a  supported  unit. 
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(5)  Identify  the  major  choke  points  of  a  resupply  activity 
and  simulate  the  processing  of  each  vehicle  through 
these  choke  points  in  seguence.  These  choke  points 
and  the  seguence  in  which  they  occur  are  as  follows: 

(a)  RSV/convoy  leaves  resupply  activity. 

(b)  RSV/convoy  is  processed  by  Aamuniticn  Supply 
Officer. 

(c)  RSV/convoy  arrives  at  resupply  activity  and  is 
in-processed. 

(d)  The  RSV/convcy  moves  to  its  respective  loading 
point . 

(e)  Loading/off-loading  takes  place. 

(f)  RSV/convoy  leaves  and  proceeds  to  an  assembly 
area. 

(g)  RSV/convoy  out-processed  through  activity  office. 

(h)  RSV/convoy  returns  to  initiating  activity. 

(6)  Give  a  good  evaluation  of  the  effect  of  enemy  activity 
on  mission  performance  by  considering  the  damage  and 
destruction  of  support  eguipment. 

(7)  Provide  a  good  tool  for  Combat  Service  Support  mission 
Area  Analysis  and  TOE  development. 
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(8)  Provide  another  check  on  performance  of  the  aray's  MHZ 
design  standards  for  handling  aunitions. 

(9)  Look  at  scenarios  under  different  environaental 
conditions. 

(10)  Provide  a  tool  for  choosing  the  optiaal  location  of 
resupply  activities  at  all  levels. 

(11)  Identify  security  shortcomings  for  different 
scenarios. 

g.  Weaknesses 

The  najor  weaknesses  of  the  aodel  are: 

(1)  Munition  consumption  and  threat  data  bases  must  be 
developed  manually  from  a  force-on-force  scenario. 

(2)  The  model  requires  extensive  coaputer  core  memory 
allocation. 

(3)  The  aodel  is  expensive  to  run. 

2.  MLS 

The  second  aodel  to  be  analyzed  is  the  Ammunition 
Resupply  Model  (ABM).  ARM  is  an  interactive,  event 
oriented,  tiae  sequenced,  coaputer  aodel  developed  to 
simulate  the  various  functions  associated  with  ammunition 
resupply  from  the  Corps  Storage  Area  (CSA)  down  to  the 
individual  weapon.  It  was  developed  by  the  Combat 
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Operations  Analysis  Directorate  (COA) ,  C&SSA,  Port 
Leavenworth,  Kansas  in  March  of  1980.  ASM  is  written  in 
FORTRAN  17  and  consists  of  approximately  3400  lines  of  code 
that  require  144K  octal  main  storage,  including  the  data 
base.  Less  than  12  CPU  seconds  are  used  in  processing  the 
resupply  actions  that  result  from  four  hours  of  combat  by  a 
division  size  force.  [Bef.  2] 

a.  Purpose 

ARM's  primary  role  is  to  assess  the  capability 
of  a  given  TOE  structure  to  respond  to  the  logistical 
demands  placed  on  it  by  various  ammunition  expenditures. 

For  model  purposes,  these  expenditures  are  created  by  a 
force- on-force  model  such  as  the  JIFFY  vargame.  ABM  was 
used  in  this  manner  to  study  the  ammunition  resupply 
capability  of  alternative  division  organizations  of  the 
Division  86  force  structure.  The  model  was  developed  in  a 
general  form  thereby  allowing  it  to  be  used  with  most  combat 
models. 

b.  Characteristics 

ARM  controls  the  flow  of  ammunition  through  a 
network  based  on  the  capacity  of  a  given  number  of  RST's  and 
supply  points.  It  also  controls  the  flow  through  the  supply 


33 


network  based  on  MHE  availability.  The  model  actually 
t 

forces  the  network  to  replace  rounds  at  individual  weapons 
at  the  unit  level,  and  sends  trucks  back  to  designated 
resupply  points  to  fill  up  and  return.  The  functions  of 
each  truck  are  broken  up  into  a  series  of  discrete  events 
portrayed  as  subroutines.  The  model  takes  each  truck 
through  a  series  of  these  subroutines  (with  operational 
availability  and  interdiction  considered)  in  which  actions 
are  completed  and  tiaes  accuaulated.  Helicopter  resupply, 
interactive  command  decisions,  and  tactical  realism  can  be 
incorporated  into  the  model, 
c.  Assumptions 

A  list  of  the  key  assumptions  made  in  ABU  are: 

(1)  Only  high  voluae/high  demand  ammunition  is  addressed. 

(2)  Artillery  units  reload  once  each  hour  during  a  battle. 

(3)  Aviation  units  reload  upon  the  return  of  an  aircraft. 

(4)  Ammunition  trucks  are  dedicated  to  a  specific  type  of 
ammunition. 

(5)  when  a  weapon  system  is  lost,  all  ammunition  is  lost. 

(6)  When  a  loaded  truck  is  interdicted,  the  load  is  lost. 

(7)  Helicopter  emergency  resupply  will  support  only  155am 
artillery  batteries  and  the  resupply  originates  at  the 
ASP. 

1 


34 


(8)  Trucks  are  sent  for  refill  only  when  empty. 

(9)  The  division  portion  of  the  corps  heavy  lift 
helicopters  will  not  exceed  10  CH-47's. 

(10)  The  division  portion  of  corps  transportation  assets 
for  ammunition  resupply  will  he  one  medium  truck 
company.  This  company  will  haul  aaaunition  directly 
from  the  CSA  to  the  ATP's  and  ISP's. 

d.  Input 

The  input  paraaeters  needed  for  the  operation  of 
the  model  are: 

(1)  Humber  and  allocation  of  ammunition  dedicated 
BSV' s/convoys  in  the  transportation  net. 

(2)  Record  of  on-hand  ammunition  from  the  scenario 
wargaae. 

(3)  Number  of  weapons  and  basic  load  of  each  type  system. 

(4)  Ammunition  hauling  capacity  of  each  BSV. 

(5)  Stockage  level  and  loading  times  at  each  ASP/ATP. 

(6)  Key  BSV  characteristics  (ie.  speed,  BAH). 

(7)  Beload  times  of  each  weapon. 

e.  Output 

Output  from  the  model  consists  of  an  audit  trail 
of  all  events  accumulated  in  a  series  of  reports  generated 
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through  a  subroutine  called  BEPOfiT.  The  following  is  a  list 
of  output  reports  available: 

(1)  status  of  each  BSV  to  include  location  and  load. 

(2)  current  ammunition  status  of  each  unit. 

(3)  Status  of  each  ATP/ASP  to  include  nuaber  of  MHE 
available,  RSV's  in  gueue  and  the  amount  of  each  type 
aaaunition  on-hand  versus  initial  stockage. 

(4)  An  interdiction  report  to  include  which  BSV's  were 
interdicted  and  the  type  and  aaount  of  ammunition 
lost . 

(5)  Emergency  resupply  information. 

f.  Strengths 

The  major  strengths  of  ABE  are: 

(1)  ARE  influences  the  gaaer's  tactical  decisions  for 
aaaunition  logistics  by  adding  scenario  generated 
constraints. 

(2)  The  aodel  can  be  used  to  deteraine  what  transportation 
assets  of  the  ASP/ATP  are  reguired  to  support  a  given 
scenario. 

(3)  ASH  aodels  individual  BSP's. 

(4)  The  aodel  gives  an  indication  of  the  capability  of  a 
given  aaaunition  resupply  systea  for  a  given  scenario. 
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g.  Weaknesses 

The  principal  weaknesses  of  ASH  are: 

(1)  ASH  does  not  model  the  internal  operations  of  the 
ASP/ATP  in  enough  detail. 

(2)  The  model  uses  estimated  straight  line  distances 
between  firing  unit  and  resupply  points  instead  of 
actual  road  distances. 

(3)  The  model  requires  a  manual  data  base  development  for 
each  scenario. 

D.  LOGISTICS  MODEL  DEVELOPMENT  AT  NPS 

The  purpose  of  this  section  is  to  examine  and  discuss 
four  previous  NPS  thesis  efforts  which  modelled  aspects  of 
logistics.  Three  of  these  efforts  are  directly  related  to 
the  STAB  model. 

Since  the  development  of  the  STAB  model  at  NPS, 
logistics  planners  have  been  given  a  unique  opportunity  to 
investigate  the  dynamic  interaction  between  the  combat  and 
the  logistics  process  at  the  most  critical  juncture,  the 
battlefield.  Since  its  initial  coding  in  1978,  the  model 
has  been  continually  expanded  to  include  an  ever  widening 
horizon  of  combat  functions.  Although  several  attempts  have 
been  made  to  integrate  logisitics  into  the  model,  little 
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logistics  is  currently  played.  This  section  will  review 
several  previous  logistics  theses  written  at  NPS.  Some 
address  STAH  directly;  others  do  not.  In  summary,  these 
works  fora  part  of  the  evolutionary  developaent  of  logistics 
modelling  at  NPS  of  which  this  aodel  is  a  part.  Discussion 
of  each  effort  will  include:  a  general  description;  an 
enumeration  of  assumptions;  a  discussion  of  the  modelling 
techniques  developed;  a  discussion  of  strengths  and 
weaknesses  of  these  techniques;  and  an  outline  of  the  aodel 
utility.  Some  of  the  concepts  developed  in  these  efforts 
are  used  in  this  ammunition  resupply  aodel;  others  will  be 
valuable  for  future  efforts. 

i .  "£iaalatioa_aa3_AaUis4§  .of  .sga&gegct  ,-ia  .sbppw*  . 
a  combat  On  it  “by,  John  .  _KeUey_il9  78)__E 
This  thesis  parametrically  analyzes  the  mission  of 
the  support  platoon  of  a  U.S.  Tank  Battalion.  The  stated 
objectives  of  the  thesis  were:  to  develop  an  overall 
logistics  aodel  that  could  be  integrated  into  a  battalion 
level  combat  simulation;  to  measure  thfc  Support  Platoon's 
ability  to  move  supplies  under  varying  conditions;  and  to 
evaluate  the  impact  of  simultaneous  forces  on  combat  support 
operations. 
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In  pursuing  these  goals,  a  Honte  Carlo  siaulation  of 
the  ammunition  resupply  process  was  developed.  The  use  of  a 
Monte  Carlo  siaulation  to  capture  the  interaction  of  forces 
on  the  resupply  process  was  a  step  away  froa  traditional 
network/pipeline  analysis  noraally  developed  for  logistics 
studies.  The  technique  involves  the  identification  and 
isolation  of  significant  variables  within  a  process, 
assignment  of  probabilities  of  occurance  to  each  variable, 
and  replication  of  the  process  described  by  these  variables 
in  order  to  achieve  an  expected  value  outcoae.  Using  this 
technique,  the  author  was  able  to  focus  attention  on 
specific  aspects  of  the  resupply  process,  to  deliberately 
vary  values  for  the  probability  of  their  occurance,  and  to 
statistically  analyze  results  for  significance, 
a.  Assumptions 

The  aajor  assuaptions  aade  by  Kelly  in  his 

thesis  are: 

(1)  The  ability  of  a  support  platoon  to  provide  ammunition 

support  to  the  battalion  is  a  direct  function  of: 

(a)  The  aaxiaua  nuaber  of  trucks  available  at  any  tine 
(Drivers  assuaed  always  available)  . 

(b)  The  maintenance  tiae  required. 

(c)  The  probability  of  aabush. 
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(d)  The  probability  of  kill  given  an  ambush. 

(e)  The  loss  of  vehicles  to  ambush. 

(f)  The  time  reguired  to  replace  lost  vehicles. 

(2)  Vehicles  can  make  a  maximum  of  three  round  trips  a  day 
to  supply  points. 

(3)  Maintenance  readiness  is  evaluted  at  the  end  of  each 
rrip.  Readiness  is  measured  against  a  fixed 
operationally  ready  (OR)  rate. 

(4)  Ammunition  is  obtained  from  a  CSA  located  at  the 
Division  rear. 

(5)  All  vehicles  in  a  convoy  are  subject  to  en°my  attack. 
Survival  of  each  vehicle  is  measured  against  a  fixed 
probability  of  kill.  Partial  damage  and  salvage  are 
not  played. 

(6)  Support  is  being  provided  to  a  "pure"  tank  battalion. 

(7)  The  effects  of  each  of  the  parameters  measured  are 
independent  and  additive. 

(8)  Measure  of  effectiveness  selected:  Truckloads  moved 
during  specified  time  periods.  (3,5,15,30  days) 

b.  Method  of  Evaluation 

Due  to  the  software  limitations  on  the  analysis 
packages  available  when  the  thesis  was  written,  the  model 
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limited  itself  to  a  consideration  of  replacement  time, 
probability  of  ambush,  number  of  round  trips  delivered  to 
supply  points  per  day,  and  maximum  number  of  vehicles 
available.  Probability  of  kill  given  ambush,  and 
probability  of  a  vehicle  becoming  non-op erationally  ready 
were  fixed  for  each  simulation  run.  The  impact  of  these  two 
factors  was  combined  into  the  mean  of  the  design. 

Having  specified  those  aspects  of  the  resupply 
process  critical  to  the  success  of  the  Support  Platoon 
mission,  a  range  of  probabilities  for  success  for  each  of 
the  critical  parameters  was  fixed  and  a  number  of  Monte 
Carlo  simulations  conducted  for  each  variation.  An  analysis 
of  the  results  was  performed  and  an  expected  value  for  each 
set  of  selected  probabilities  was  computed.  The  analysis 
conducted  also  measured  the  effects  of  each  individual 
component,  and  its  interaction  with  the  other  elements. 

As  a  final  demonstration  of  the  methodology,  a 
conflict  set  in  a  European  scenario  was  developed  and  a 
simulation  conducted.  Values  for  each  of  the  four  critical 
parameters  were  varied  in  response  to  the  scenario 
conditions,  and  in  accordance  with  the  judgement  of  the 
writer.  A  regression  performed  on  the  results  fitted  a 
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linear  model  to  the  data  to  check  the  linear  fit  of  the 
postulated  model.  Parameters  again  were  varied,  results 
tallied,  and  tested  for  significance. 

c.  Strengths 

The  study  achieved  its  objective  of  formulating 
and  exercising  a  resupply  simulation  within  the  bounds  of 
those  parameters  hypothesized  as  being  critical.  Accepting 
the  premise  that  the  factors  modelled  captured  the  critical 
essence  of  the  resupply  process,  the  technigue  used  in  the 
thesis  could  be  modified  and  used  in  a  generalized  combat 
model  to  return  a  value  of  total  tonnage  of  supplies 
delivered  during  a  specified  time  period. 

The  primary  conclusion  of  the  analysis 
conducted,  that  the  probability  of  enemy  attack  and  the 
physical  location  of  the  resupply  point  were  the  driving 
forces  behind  the  model,  dictates  that  such  parameters  be  of 
prime  importance  to  any  resupply  model. 

d.  Weaknesses 

The  major  weaknesses  found  in  the  model  are: 

(1)  Conceptual  limitation  to  those  parameters  defined  as 
critical.  Use  of  parameters  other  than  *hose  specified 
and  tested  in  the  thesis  would  seriously  weaken  the 
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conclusions  Bade  in  the  thesis  and  could  lead  to 


incorrect  results. 

(2)  Current  doctrine  to  include  the  creation  and  use  of 
Ammunition  Transfer  Points  (ATP's)  was  not  considered. 

(3)  Operationally  Beady  (OB)  rates  are  normally  determined 
on  a  daily  basis  rather  than  after  each  supply  trip  as 
proposed. 

e.  Utility 

This  model  could  best  be  utilized  in  the 
following  manner: 

(1)  The  method  developed  and  the  results  generated  by  the 
model  would  best  be  utilized  as  a  generalized 
constraint  to  a  high  resolution  combat  model  orr  after 
some  data  analysis,  as  logistics  coefficients  in  a 
Lanchester  model. 

(2)  The  major  finding  of  the  model  was  that  distance  and 
probability  of  enemy  activity  were  the  driving 
parameters  in  the  determination  of  overall  mission 
accomplishment.  As  such,  development  of  any  resupply 
nodel  should  consider  those  parameters  identified  as 
critical  in  their  structure. 
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2. 


"Simulation  of  Tactical  Alternative  Responses"  by  M. 
5 •  Wallace  and  2 . _G .  Hagewood  (1978)  f Ref . _4  ] 

This  thesis  and  the  follow-on  work  conducted  by 
Wallace  and  Hagewood  after  their  graduation  from  HPS  formed 
the  basis  of  what  is  now  the  STAR  model.  This  original  work 
was  designed  as  a  high  resolution,  event  sequenced, 
stochastic  aodel  of  ground  coabat.  The  language  used  was 
SINSCRIPT  II. 5.  Since  auch  of  what  was  developed  is  still 
an  integral  part  of  the  present  aodel,  this  docuaent  is 
still  a  vital  reference  tool.  In  building  the  siaulation, 
logistics  effects  were  modelled  in  three  ways.  These  were: 

(1)  The  use  of  logistics  as  an  engageaent  constraint  by 
asking  the  question,  "Do  I  have  this  ammunition 
on-hand  to  fire?" 

(2)  The  use  of  logistics  as  a  tiae  constraint  by  asking 
the  question,  "Given  that  I  have  this  ammunition  on 
board  the  tank,  what  storage  coapartaent  is  it  in,  how 
long  will  it  take  ae  to  access  it  and  aove  it  to  the 
ready  rack?" 

(3)  The  aodelling  of  logisitical  aethods  to  create  supply 
caches  in  order  to  resupply  coabat  elements. 
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Of  these  three  atteapts  to  model  the  effect  of 
logistics  on  the  combat  process,  only  the  first,  logisitics 
as  an  engagement  constraint  is  currently  used.  The  use  of 
logistics  as  a  firing  constraint  was  abandoned  after  the  AH1 
stowed  load  study  was  completed.  This  constraint  could 
easily  be  added  to  the  existing  STAR  model  but  at  the 
present  time  such  a  high  degree  of  resolution  is 
inappropriate.  The  modelling  of  resupply  caches  was 
abandonned  because  at  that  stage  of  the  model's  development, 
the  contribution  of  the  caches  was  of  marginal  value  when 
weighted  against  the  time  required  to  prepare  the  data  and 
the  CPU  time  required  to  execute  the  logic.  Tanks  on  the 
battlefield  were  killed,  or  the  battle  was  ended  before 
resupply  was  necessary  and  so  the  logic  modelled  became 
superfluous. 

Each  of  the  three  atteapts  to  incorporate  logistics 
effects  however,  is  worth  analyzing  in  order  to  gain  insight 
into  the  interplay  of  forces  within  STAR,  and  to  gain 
modelling  insight  through  access  to  existing  working  code, 
a.  Methodology 

The  general  methodology  of  this  aodel  is  as 

follows: 
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(1)  Resupply  As  A  Firing  Constraint  -  in  this  logic, 

aaaunition  availability  is  played  as  a  constraint  to 
firing.  The  logic  developed  tracks  on-hand  aaaunition 
by  type  for  each  tank.  At  the  beginning  of  a  firing 
sequence,  a  round  is  selected  and  its  on-hand 
availability  is  screened  on  a  go/no  go  basis.  In 
iapleaentation,  aaaunition  is  aodelled  at  two  critical 
junctures,  when  selecting  the  aaaunition  to  fire,  and 
upon  round  impact.  The  first  juncture  is  controlled 
by  routine  PRIORITY. AND. ROUND. SELECT.  This  routine 
assesses  the  relative  iaportance  of  the  target 
currently  selected,  chooses  a  preferred  round  for  use 
against  the  target,  and  checks  to  see  if  the  stocks  of 
the  round  are  available.  In  performing  this  function, 
the  routine  accesses  a  matrix  called  a  DANGER  STATE 
array  to  deteraine  the  priority  of  the  target,  and  to 
select  the  aaaunition  to  be  fired,  Routine 
PRIORITY.  AND, ROUND. SELECT  then  calls  routine 
AMflO. CHECK  which  screens  the  aaaunition  attributes  of 
the  specific  tank  to  deteraine  if  the  aaaunition  is 
available.  The  second  juncture  occurs  at  the  tiae  the 
round  is  scheduled  to  iapact.  As  part  of  the  logic. 


routine  DECREMENT. AMMO  is  called  to  subtract  one  round 


of  the  type  of  aaaunition  fired  froa  the  tank  which 
fired. 

(2)  Resupply  As  A  Liaitation  On  Firing  Tiae  -  the  logic 
developed  for  this  aspect  of  logistics  was  done  in 
support  of  the  XM1  tank  stowed  load  study.  It 
aodelled  the  tiae  reguired  to  physically  aove  rounds 
inside  an  XH1  in  an  effort  to  add  a  degree  of  realisa 
to  the  play  by  restricting  the  access  to  aaaunition  on 
the  tank.  This  logic  aodelled  the  tiae  reguired  to 
aove  rounds  froa  one  of  five  storage  coapartaents  on 
the  tank  to  the  ready  rack.  This  level  of  detail  was 
later  judged  to  be  unnecessary  in  the  noraal  use  of 
the  aodel. 

(3)  Resupply  -  additional  work  after  thesis  coapletion 
atteapted  to  extend  aaaunition  concepts  to  include  the 
aoveaent  of  supplies  froa  storage  areas  to  resupply 
caches.  The  focus  of  this  logic  was  a  Supply  Officer 
entity  who  controlled  a  nuaber  of  caches  in  support  of 
his  unit.  These  caches  are  planned  prior  to  prograa 
execution.  In  the  execution,  a  routine  PILE. SO. CREATE 
calls  a  nuaber  of  subprograas  which  loads  trucks  at 
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the  ATP  (event  LOAD. PLAN),  aoves  loads  to  a 
pre-planned  cache  site  (event  MOVEOUT)  ,  and  offloads 
the  aaaunition  at  the  site  (event  OFFLOAD) .  Resupply 
of  the  coabat  vehicles  (event  OPLOAD)  was  accoaplished 
when  the  unit  withdrew  to  the  location  of  the  cache, 
b.  Strengths 

The  major  strengths  of  the  aodel  are: 

(1)  Logistics  As  An  Engageaent  Constraint  -  the  logic 
developed  directly  tracks  the  on-hand  balance  of  6 
types  of  aaaunition  for  each  weapon  systea.  This  is  a 
basic  start  point  for  any  aodel  that  hopes  to  aodel 
logistics  in  STAR  realistically. 

(2)  Resupply  As  A  Limitation  To  Firing  -  although  this 
code  proved  to  be  of  value  in  the  XH1  stowed  load 
study,  the  decision  to  turn  off  the  code  was  aore  a 
function  of  lack  of  utility  than  absolute  uselessness. 
The  logic,  in  fact,  provides  an  iaaediate  tie-in  for 
any  future  aodelling  of  delivery  of  a  resupply  of 
rounds  to  the  coabat  units. 

(3)  Other  logic  developed  depicts  the  loading  and 
unloading  of  supply  trucks  and  coabat  vehicles, 
creation  of  caches  at  pre-designated  points,  and  a 
rudiaentary  stock  control  systea. 
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c.  Weaknesses 


The  weaknesses  of  this  aodel  were  perceived  in 
the  following  areas: 

(1)  There  was  no  overall  logic  developed  to  dynamically 
control  and  integrate  logistics  play  within  the  model. 
Tanks  will  continue  to  fire  until  ammunition  stocks 
are  exhausted.  Besupply  caches  are  entirely 
pre-programmed  and  once  execution  begins,  the  dynamic 
flow  of  the  battle  will  not  change  the  creation  of 
stocks. 

(2)  The  assets  possessed  by  a  unit  will  not  influence  the 
tactical  decision  process.  Logistics  influence  is 
limited  strictly  to  fire/no  fire  control. 

d.  Utility 

The  SI HSC HIP?  coding  developed  is  fully  and 
immediately  integratable  into  STAB  and  thus  represents  an 
excellent  start  point  for  any  new  logistics  study.  The 
basic  STAB  aodel  interface  points  still  exist.  If  future 
STAB  logistics  modellers  understand  this  logic  they  will 
save  themselves  considerable  tiae  and  effort. 

The  iaaediate  extension  of  this  logic  includes 
recognition  and  use  of  the  current  aaaunition  status  to 
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trigger  resupply  actions.  Further  extensions  include  the 
use  of  aaaunition  status  no  modify  tactical  courses  of 
action  or  to  trigger  a  request  to  move. 


gf-^s-STAB_floaei«i_&z_S£asg_s.,gieiejE_J1222L,[  MI* 
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This  thesis  presents  a  conceptual  framework  for 
modeling  logistics  functions  within  a  combat  brigade.  The 
objective  of  the  thesis  was  to  develop  a  logical  structure 
for  the  modelling  of  ammunition  and  fuel  resupply.  It  was 
hoped  that  this  logical  structure  would  lay  a  basis  for  the 
future  development  of  detailed  logistics  logic  to  be  entered 


into  STAS. 

The  medium  chosen  to  depict  this  framework  was  a 
network  diagram.  The  primary  product  of  the  thesis  was  the 
development  of  this  network  and  associated  parameters 
essential  to  modelling  resupply.  Resolution  of  a  fully 
developed  model  using  this  logic  would  depict  individual 
trucks  carring  rounds  of  aaaunition  from  the  brigade  trains 
to  the  combat  vehicles.  Aaaunition  would  be  measured  by  the 
"box",  a  generic  term  used  to  represent  all  packaging 
configurations  from  the  individual  round  to  a  pallet  of 
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rounds.  Petroleum  would  be  measured  in  bulk  terms  only; 
packaged  petroleum  is  not  played, 
a.  Assumptions 

The  major  assumptions  made  in  this  model  are: 

(1)  Battalion  trains  are  located  5  Km  and  brigade  trains 
are  located  25  Km  behind  the  PEBA. 

(2)  Corps  will  transport  ammunition  from  the  Corps  storage 
Area  (CS1)  in  the  Corps  Hear  Area  to  the  Ammunition 
Supply  Points  (ASP*s)  located  in  the  Division  Bear  and 
the  Ammunition  Transfer  Points  (ATP's)  located  in  each 
of  the  brigade  areas. 

(3)  Corps  ammunition  support  to  the  division  will  be 
provided  by  two  conventional  ammunition  companies  with 
each  company  operating  two  ASP's. 

(4)  capabilities  of  ammunition  points  are  as  follows: 

(a)  ASP  -  Receipt  and  issue  of  2000  short  tens  of 
ammunition  daily. 

(b)  ATP  -  Receipt  and  issue  of  500-600  short  tons  of 
ammunition  daily. 

(5)  Only  5  ton  trucks  are  capable  of  making  the  round  trip 
from  the  battalion  trains  to  an  ASP  and  back.  APARV's 
and  GOER'S  are  limited  to  trips  to/from  the  ATP's  at 
brigade. 
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{6)  Vehicles  will  travel  only  in  convoys. 

(7)  Operationally  ready  rates  (OS)  are  computed  once  daily 
according  to  the  following  rates: 

(a)  Material  Handling  Equipment  (MHE)  -  75% 

(b)  Bn  Ammo  Vehicles  -  85% 
b.  Characteristics 

The  resupply  framework  was  developed  around  the 
traditional  supply  HOE  of  ascertaining  the  number  of 
truckloads  of  aaaunition  delivered  per  unit  time.  In 
execution,  the  network  traces  the  movement  of  trucks  of 
varying  dimensions  through  a  network  subject  to  uniformly 
distributed  movement  and  loading  times. 

(1)  Network  Development  -  the  key  to  the  thesis  work  was 
the  development  of  the  network  diagram  itself.  The 
network  depicts  the  flow  of  supplies  from  division  and 
brigade  storage  areas  to  the  battalion  trains. 

Central  to  this  concept  was  the  determination  of  the 
number  and  characteristics  of  carriers,  arcs,  and 
nodes  which  make  up  the  system. 

(a)  Carrier:  the  term  used  to  represent  the  actual 
supply  trucks  on  the  network.  Each  carrier  type 
has  specific  weight  and  cube  limitations.  These 
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limitations  are  used  to  constrain  a  vehicle's 


capability  to  transport  ammunition.  The  carrier 
is  the  critical  focus  of  the  system,  since 
determination  of  the  quantity  delivered  per  unit 
time  is  based  on  the  carrier's  successful 
completion  of  trips  tc/from  the  supply  points. 

(b)  Arc:  the  term  used  to  represent  road  segments  on 
the  ground.  Arcs  direct  traffic  flew  and  are  used 
to  determine  straight  line  travel  time  between 
points.  Load  capacity  of  roads  is  depicted  by 
limitations  on  vehicle  speeds  on  individual  arcs, 
for  example,  10  mph  over  unimproved  roads.  Boad 
congestion,  although  identified  as  potentially  a 
major  problem,  was  not  explicitly  modelled. 

(c)  Modes:  these  mark  points  of  change  within  the 
network  itself.  Two  types  of  nodes  were  specified, 
load  state  changes  and  travel  state  changes.  Load 
state  changes  mark  those  locations  where 
ammunition  is  loaded  and  unloaded.  Activity  at 
these  points  is  modelled  as  time  delays  generated 
from  specified  distributions.  Operationally,  these 
delays  would  be  modelled  as  a  function  of  the 
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number  of  people  at  the  point,  the  number  of  HH£ 
pieces  at  the  point,  the  capacity  of  the  carrier, 
and  the  length  of  the  queue  at  the  resupply 
location.  Travel  state  changes  represent  those 
points  on  the  network  at  which  direction  of  travel 
changes.  These  points  represent  travel  through 
cities,  past  major  intersections,  and  through 
points  of  congestion. 

(2)  Movement  And  Load  Times  -  a  second  key  aspect  of  this 
framework  is  the  concept  of  time  use.  All  times 
within  the  model  are  assumed  to  be  uniformly 
distributed  about  a  calculated  mean.  Thus  travel  time 
along  a  stretch  of  highway  is  based  on  the  length  of 
the  roadway  and  on  the  assumed  speed  of  the  vehicle. 

To  this,  an  induced  variability  of  plus  or  minus  20* 
was  introduced  to  allow  some  further  randomization  of 
vehicle  times.  Load/unload  times  were  based  on  an 
assumed  loading  time  for  the  particular  load  on  a 
specific  cargo  carrier.  Thus,  ammunition  cargo  varied 
by  the  "box”  configuration  to  be  handled,  while  fuel 
loading  varied  in  accordance  with  the  load  capacity  of 
the  pump  assumed  to  be  at  the  location. 
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c.  Strengths 

The  strong  points  of  this  model  are: 

(1)  The  thesis  successfully  established  a  network:  diagram 
which  adequately  captures  the  various  activities  which 
make  up  the  supply  chain.  Tie  example  illustrated  in 
the  thesis  is  in  generalized  enough  terms  to  be  easily 
adaptable  to  any  particular  setup. 

(2)  Although  designed  for  a  foethan  simulation,  the 
descriptors  used  to  model  the  flow  of  the  network  can 
be  adapted  to  any  simulation  language.  These  critical 
descriptors  and  the  information  they  convey  are  as 
follows: 

(a)  Arcs:  length  of  road  segment;  type  of  road 
(unimproved, etc. ) ;  average  vehicle  speed  on  the 
road;  amount  of  congestion  on  the  road. 

(b)  Nodes:  type  (road  junction, supply  point, town, etc)  ; 
average  delay  time  expected. 

(c)  Carriers: 

•  Ammunition  Carriers  -  type,  max  cargo 
weight,  operationally  ready  status;  location; 
amount  of  cargo  on  board;  type  of  cargo  on  board; 
unit. 
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•  Petroleum  Carriers  -  type;  fuel  carried; 
amount  carried;  gallon  capacity;  pump  rate. 

(d)  "BOX"  of  Ammo:  weight  of  package;  volume  of 
package;  number  of  rounds/box. 
d.  Weaknesses 

Some  of  the  major  weaknesses  perceived  by  the 
authors  in  the  model  are: 

(1)  In  briefly  outlining  assumptions,  locations  of  support 
units  were  discussed  in  terms  of  fixed  distances 
rather  than  as  envisioned  in  the  more  flexible  design 
doctrine  called  for.  In  fact ,  present  doctrine  calls 
for  the  battalion  trains  to  normally  divide  assets 
between  two  locations,  the  combat  trains  and  the  field 
trains.  Combat  trains  are  located  5-7  Km  behind  the 
FEBA  while  the  field  trains  are  located  10-15  Km 
behind  the  FEBA.  The  composition  of  either  is 
flexible;  however,  the  bulk  of  ammunition  supplies  is 
normally  maintained  at  the  field  trains.  Brigade 
trains  are  normally  located  15-25  Km  behind  the  FEBA 
and  so  could  conceivably  be  co-located  with  the 
battalion  trains.  The  central  considerations  which 
dictate  the  location  of  these  facilities  is  the 
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nission  of  the  unit  and  the  range  of  eneny  aediua 
artillery . 

(2)  The  vehicle  load  tines  for  various  annunition  types 
were  established  for  illustrative  purposes.  More 
realistic  distributions  must  be  developed  for  actual 
appl ications. 

(3)  No  provisions  were  nade  to  aodel  hostile  action  on  the 
network. 

(4)  No  queue  was  explicitly  established  at  any  supply 
point. 

(5)  The  network  was  self-contained  and  designed  to  aodel 
only  the  aovenent  of  battalion  trucks  on  the  network. 

(6)  Once  a  resupply  vehicle  arrived  at  the  battalion 
trains,  resupply  was  considered  completed.  No  atteapt 
was  aade  to  aodel  the  loading  of  annunition  on  conbat 
vehicles. 

(7)  There  was  no  decision  logic  developed  to  dynaaically 
control  the  network  or  to  react  to  a  change  coaaand 
once  the  vehicles  were  set  in  notion. 

e.  Otility 

The  network  designed  is  an  excellent  starting 
point  for  the  development  of  resupply  logic  at  the 
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battalion/brigade  level.  The  detailed  development  of  the 
essential  elements  of  this  network  is  a  first  cut  at  molding 
the  disparate  elements  of  resupply  into  a  coherent  process. 

4 •  MA  High  Resolution  Integrated  Combat  and  Logistics 
Model11  by  D . G .  Kirby  and  D. £.  Schultz  <1 9801  r  Be$. 

6] 

This  thesis  was  the  first  attempt  to  integrate  the 
effect  of  logistics  in  the  STAR  model.  The  objective  of  the 
work  was  to  design  a  broad  flowchart  of  the  programming 
logic  required  to  model  logistics  and  to  investigate  a  means 
of  modelling  the  command  and  control  decision  processes 
which  overlay  this  process.  The  authors  limited  their 
discussion  to  the  resupply  of  petroleum  and  ammunition.  In 
depicting  this  development,  the  authors  utilized  the 
Software  Decision  and  Documentation  Language  (SDDL)  which 
outlines  the  logic  of  the  program  in  the  fora  of  a  detailed 
flowchart. 

a.  Assumptions 

The  major  assumptions  made  by  Kirby  and  Schultz 

are: 

(1)  The  Battalion  Support  Platoon  is  solely  responsible 
for  battalion  resupply.  Ammunition  is  obtained  from 
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either  the  ATP  run  by  DISCOS,  or  from  the  ASP  run  by 
corps.  Petroleum  is  obtained  froa  DISCOH  tankers 
spotted  in  the  Brigade  Supply  Area. 

(2)  Resupply  can  be  acconplished  either  by  moving  supplies 
forward  to  the  combat  vehicles  (unit  resupply) ,  or  by 
pre-positioning  ammunition  at  specified  locations 
(Cache)  . 

(3)  Supply  vehicles  carry  homogeneous  loads.  Bo 
cross-leveling  of  cargo  between  supply  trucks  is 
permitted. 

(4)  Ammunition  will  not  be  redistributed  between  elements 
of  a  unit. 

b.  Methodology 

The  logic  designed  can  be  divided  into  three 

categories : 

(1)  Command  logic  within  a  battalion. 

(2)  Onit  resupply  logic. 

(3)  Supply  point  resupply  logic. 

The  critical  development  by  the  authors  was  the 
design  of  the  command  decision  logic;  flow  for  the  other  two 
categories  was  relatively  transparent.  Command  logic  is  used 
primarily  to  evaluate  the  current  supply  situation  and  to 
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determine  a  priority  for  resupply.  The  key  tc  this  logic 
lies  in  the  development  of  the  concept  of  Level  of  Need 
(LON)  . 

Level  of  Need  (LON)  is  a  categorical  structure 
through  which  the  resupply  situation  of  a  unit  is  expressed. 
It  represents  the  ratio  of  supplies  on-hand  to  the  total 
capacity  of  the  unit.  The  authors  define  four  Levels  of 
Need;  full,  want,  approaching  critical,  and  critical.  LON 
is  computed  for  each  firing  system  with  regard  to  its 
primary  ammunition  and  its  fuel  status  only.  The  lowest 
category  computed  for  either  determines  the  overall  LON  for 
the  weapon  system.  At  the  platoon,  this  logic  models  the 
platoon  leader  examining  the  LON  of  each  of  his  vehicles. 

The  platoon  is  then  assigned  an  LON  based  on  the  category  it 
falls  under.  This  platoon  logic  is  duplicated  at  each 
company,  battalion,  and  brigade  in  the  resupply  chain 
thereafter. 

Decision  logic  for  resupply  uses  this  LON  and 
combines  it  with  a  consideration  of  supplies  available  for 
issue  and  an  evaluation  of  the  suppression  level  at  the  unit 
being  resupplied.  A  listing  of  all  requests  is  then 
prioritized  in  accordance  with  the  above  criteria.  Ties  are 
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broken  in  favor  of  the  unit  with  me  greatest  number  of 
weapon  systems  alive,  the  thought  being  that  maximization  of 
available  combat  power  is  a  commanders  first  concern. 

c.  Strengths 

The  thesis  clearly  outlines  those  essentials 
necessary  for  the  modelling  of  resupply.  Although  no  code 
was  developed,  the  flow  diagram  developed  illuminates  the 
path  to  be  taken.  Decision  logic  is  always  a  difficult  area 
to  model.  Development  by  the  authors  of  a  conceptual  basis 
for  this  process  is  invaluable.  By  specifying  the  urgency  of 
need  through  the  concept  of  LON  the  authors  made  the 
resupply  decision  logic  workable.  This  procedure  for 
prioritizing  resupply  efforts  based  on  the  factors 
enumerated  outlines  a  clear  and  realistic  model  of  the 
commander* s  thought  process. 

d.  Weaknesses 

Presentation  of  a  combined  LON  depicting  the 
fuel  and  ammunition  situation  is  unrealistic.  The  need  for 
ammunition  and  fuel  must  be  assessed  separately  as  each 
impacts  on  the  tactical  situation  in  a  different  manner.  In 
fact,  a  further  sub-division  within  these  categories  as  to 
type  of  fuel  and  type  of  ammunition  would  present  a  clearer 
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and  aora  realistic  picture  upon  which  to  base  tactical 
decisions.  The  aethod  of  coabining  LON  at  platoon  and  above 
based  on  a  predominant  LON  and  on  a  subjective  assessment  of 
the  relative  importance  of  tactical  systems  is  also 
unrealistic.  Again  a  sub-division  of  information  into  types 
of  ammunition  and  types  of  fuel  needed  would  add  a  clearer 
and  more  realistic  dimension  to  the  problem  play.  Failure 
of  the  authors  to  develop  logic  for  the  redistribution  of 
on-hand  assets  is  unrealistic.  Addition  of  such  logic  would 
present  a  truer  picture  of  the  real  process  within  units. 
Lastly,  consolidation  of  ammunition  on-hand  at  the  platoon 
level  and  above  must  include  a  consolidated  count  of  all 
assets  on-hand,  including  reserve  assets.  Failure  to  do 
this  would  again  cause  decisions  to  be  based  on  unrealistic 
data. 

e.  Utility 

This  thesis  illuminates  the  path  of  development 
for  future  logistic  modelling  in  STAB.  The  flowcharts 
presented  are  detailed  and  thorough.  They  totally  explain 
the  resupply  network.  This  concept  of  modelling  the 
decision  framework  overlaying  the  supply  network,  while 
needing  significant  revisions,  steers  future  efforts  in  the 
right  direction. 


Ill .  MODEL  DESCRIPTION 


A.  IN TROD OCT ION 

This  chapter  presents  an  overview  of  the  aaaunition 
resupply  aodel  developed  for  this  thesis.  It  discusses  each 
of  its  parts  in  general  teras  and  lists  its  major 
assuaptions.  A  detailed  discussion  of  the  aodel,  to  include 
an  explanation  of  the  SIMSCRIPT  II. 5  prograaaing  language 
and  the  aodel  code  developed  is  presented  in  Appendicies  A 
and  B. 

The  resupply  aodel  presented  in  this  thesis  is  a 
stochastic,  discrete- evant  siaulation  implemented  in  the 
SIMSCRIPT  II. 5  prograaaing  language  depicting  aaaunition 
resupply  procedures  within  a  coabat  battalion.  The  basic 
structure  of  the  aaaunition  support  flow  is  taken  fro a  Army 
Pield  Manual  9-6,  Aaaunition  Service  in  the  Theatre  of 
Operations  [Ref.  7].  The  aodel  is  designed  to  provide  a 
flexible  fraaework  within  which  the  user  aay  specify  the 
Tables  of  Organization  and  Eguipaent  to  be  played  and  the 
critical  resupply  levels  which  will  result  in  a  resupply 
action.  In  its  present  fora  the  aodel  can  play  an  unliaited 
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number  of  weapon  systems  and  ammunition  types,  however,  each 
individual  system  is  limited  to  a  maximum  of  6  ammunition 
types. 

Section  B  of  this  chapter  discusses  the  battle  used  in 
generating  the  data  for  the  model. 

Section  C  explains  how  ammunition  expenditures  are 
tracked  from  the  weapon  to  battalion  and  how  such 
expenditures  thereby  trigger  resupply  action  by  the  chain  of 
command. 

Section  D  discusses  the  resupply  logic  used  at  each 
level  of  command  in  evaluating  the  availability  of  on-hand 
ammunition  and  determining  both  the  guantities  released  and 
priority  of  resupply. 

Section  E  explains  how  the  redistribution  of  on-hand 
ammunition  assets  is  modelled  and  when  it  takes  place. 

B.  THE  BATTLE 

The  purpose  of  the  battle  in  this  model  is  to  generate 
requirements  that  will  force  a  response  from  the  ammunition 
resupply  logic  developed.  Initially,  the  authors  intended 
to  use  the  STAB  model  as  a  source  for  input  data,  since  a 
record  of  ammunition  expenditures  is  normally  generated  as 
part  of  its  output.  In  the  present  configuration  of  STAB, 
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however,  the  battle  terminates  veil  before  ammunition 
resupply  ever  becomes  critical,  so  a  direct  tie-in  to  the 
model  was  deemed  impractical,  in  alternate  proposal  for 
generating  data  from  multiple  STAfl  runs  was  also  rejected  as 
too  cumbersome. 

Instead,  it  was  decided  to  generate  the  needed  data 
through  the  use  of  Lanchester  equations  and  Hcnte  Carlo 
techniques.  Admittedly,  considerable  realism  and  resolution 
are  lost  in  doing  this,  but  the  simplification  permits  the 
generation  of  necessary  data  without  the  use  of  a 
prohibitive  amount  of  computer  time  exercising  the  STAB 
model.  It  is  important  to  keep  in  mind  throughout  the  model 
that  the  battle  generated  is  unrealistic  and  is  used  solely 
as  an  expedient  to  generate  data  for  the  logistics  model. 

Examples  of  the  types  of  data  generated  by  the  battle 
for  use  in  the  resupply  model  are: 

•  Ammunition  Expenditures  Over  A  Given  Time  Period  -  this 
data  is  generated  for  each  weapon  system  in  the  battle 
and  each  ammunition  type  it  might  possess. 

•  Damaged  And  Destroyed  Vehicles  -  combat  and  resupply 
vehicles  are  periodically  checked  for  battle  damage  by 
evaluating  random  number  draws  against  a  set  of  damage 
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probabilities  assigned  by  the  user  to  each  type  of  blue 
vehicle  in  the  model. 

•  Movement  Of  (Jnits  -  within  the  present  model  movement  of 
company  units  is  accomplished  on  a  random  basis.  The 
purpose  of  such  moves  is  solely  to  execute  the  model's 
redistribution  logic. 

The  major  assumptions  underpinning  the  battle's 
architecture  are: 

•  Battles  are  fought  for  6  hours  a  day.  The  start  time  of 
the  battle  is  determined  by  a  random  draw. 

•  Bach  weapon  type  of  a  weapon  system  has  a  rate  of  fire 
assigned  through  user  input.  However,  the  same  weapon 
on  a  different  system  can  be  assigned  a  different  rate 
of  fire  if  the  user  so  desires. 

•  Ammunition  expenditures  are  generated  in  the  model  by 
evaluating  random  number  draws  against  weapon  system 
probabilities  of  fire  for  each  armament.  Expenditures 
are  then  computed  by  multiplying  the  rate  of  fire  for 
that  armament  times  the  elapsed  battle  time  for  that 
particular  day. 

•  Combat  vehicle  damage  is  assigned  os  a  random  basis  over 
four  types  of  kills  :  firepower  kills,  mobility  kills. 


66 


aobili ty/firepower  kills,  and  catastrophic  kills.  For 
all  types  of  damage  except  firepower  kills,  ammunition 
on  board  that  vehicle  is  considered  lost.  Ammunition 
assets  belonging  to  a  vehicle  that  sustains  a  firepower 
kill  are  assumed  undamaged,  and  are  immediately 
redistributed  to  the  other  fighting  vehicles  within  that 
fighting  system's  respective  platoon. 

•  Movement  is  restricted  to  company  units  and  can  take 
place  only  after  that  day's  battle. 

C.  REQUESTS  FOB  RESUPPLY 

Expenditures  of  ammunition  by  individual  weapons  form 
the  basis  of  resupply  activity  in  the  model.  Key  to  this 
process  is  a  concept  called  level  of  need  (LON) .  A  level  of 
need  is  evaluated  for  each  ammunition  carried  by  a  combat 
entity  in  the  simulation.  These  individual  vehicle  LON's 
are  aggregated  to  form  LON's  for  each  platoon  and  company  in 
the  model.  The  purpose  of  the  LON  is  to  provide  a  measure 
of  the  urgency  of  need  a  weapon  or  unit  has  for  a  particular 
ammunition  type.  An  entity's  LON  is  updated  over  uniformly 
distributed  time  intervals  independently  of  other  vehicles 
or  units  in  the  model.  This  technique  was  implemented  in 
order  to  capture  some  sense  of  the  imperfect  information 
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that  is  inevitably  generated  and  passed  in  any  supply 
system.  The  purpose  of  this  section  is  to  explain  this 
resupply  request  process  and  to  discuss  the  effect  of  and 
reaction  to  the  imperfect  information  by  the  chain  of 
command. 

1  •  Level  of  Need  (LON) 

Level  of  need  is  a  concept  that  was  originally 
developed  by  Kirby  and  Schultz  in  March  of  1980.  The  basic 
idea  they  developed  is  adopted  for  use  in  this  model  with 
some  major  alterations.  The  concept  of  a  level  of  need  was 
adopted  because  it  represents  a  single  unifying  idea  that 
will  allow  the  expansion  of  this  model  to  all  classes  of 
supply. 

Level  of  need  describes  the  urgency  of  need  a  weapon 
has  for  a  particular  type  of  ammunition.  This  urgency  is 
then  sequentially  passed  to  and  evaluated  at  each  level  in 
the  chain  of  command  until  a  level  is  reached  which  can 
respond  appropriately,  k  separate  LON  is  computed  for  an 
ammunition  type  at  the  weapon,  platoon,  company,  and  so  on 
with  information  from  each  lower  level  being  fed  into  the 
computation  of  the  LON  of  its  immediate  superior.  In 
effect,  this  forces  each  level  to  respond  to  the  battle 
flow. 
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The  actual  value  for  an  LON  is  assigned  based  on  the 
Measured  percentage  of  fill  (amount  on-hand  /  base  load)  of 
an  ammunition  type  at  a  particular  moment.  The  essential 
idea  is  to  have  threshold  values  for  the  percent  fill  of  an 
ammunition  type  which  will  trigger  a  leader's  actions.  The 
benchmark  for  this  computation  is  called  a  base  load  for 
that  ammunition  type.  An  LON  continually  changes  as 
individual  weapon  entities,  each  with  its  own  ammunition 
configuration,  are  damaged  or  destroyed. 

At  the  weapon  level,  base  load  is  equal  to  the 
initial  stowed  load  for  the  particular  ammunition  in  the 
weapon  system.  This  load  can  be  different  for  each  weapon 
system  within  a  platoon.  An  ammunition's  base  load,  for  a 
platoon,  is  equal  to  the  sum  of  all  stowed  loads  of  alive 
systems  in  the  platoon  possessing  that  ammunition  type.  A 
company's  base  load  is,  in  turn,  determined  by  summing  over 
the  base  loads  within  its  platoons  and  so  forth. 

Level  of  need  within  the  model  is  divided  into  5 
categories,  the  thresholds  of  which  are  controlled  by  user 
input.  These  5  categories  are  defined  as  follows: 

a.  Pull  -  a  weapon  or  unit  has  enough  of  its  base 

load  of  an  ammunition  on-hand  that  no  resupply  is 
warranted  for  that  ammunition  type. 
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b.  Want  ("4")  -  the  weapon  or  unit’s  on-hand  load  is  below 
full,  but  is  not  in  a  position  to  jeopardize  the 
mission.  Reaching  a  "WANT"  LON  initiates  a  resupply 
action  at  the  lowest  priority. 

c.  Approaching  Critical  (”3M)  -  this  level  implies  that 
the  weapon  or  unit’s  on-hand  ammunition  is  at  a  level 
warranting  a  higher  urgency  of  need  for  resupply  and  a 
greater  priority  for  fill  when  ammunition  becomes 
available  than  the  "WANT”  level. 

d.  Critical  (”2’’)  -  the  weapon  or  unit's  on-hand 
ammunition  has  reached  a  level  that  seriously  endangers 
mission  accomplishment  to  the  point  that  survival  of 
the  weapon  or  unit  may  become  a  problem.  Immediate 
action  is  essential. 

e.  Empty  ("I")  -  the  weapon  or  unit  has  no  on-hand  balance 
for  a  particular  ammunition  type  and  is  no  longer  able 
to  perform  its  mission. 

Weapon  and  unit  LON  thresholds  for  the  above 
categories  are  left  as  user  inputs  and  must  be  supplied  by 
the  user  for  each  combination  of  ammunition  type  and  level 
of  command.  A  tank  then  has  different  threshold  values  for 
the  several  ammunition  types  it  carries.  This  corresponds 
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to  placing  degress  of  importance  on  types  of  ammunition. 

So,  while  a  tank  might  be  considered  critical  for  APDS 
rounds  when  it  reaches  30X  of  its  stowed  load,  it  might  not 
become  critical  for  50  caliber  ammunition  until  it  reached 
10X  of  its  stowed  load.  At  the  platoon,  the  threshold 
values  for  these  same  ammunition  types  would  be  different 
from  those  of  the  individual  fighting  systems.  This  models 
a  platoon  leader's  wider  perspective  on  a  battle  situation. 
This  situation  is  repeated  at  successively  higher  levels  of 
command. 

2.  Bequests  for  Besupply 

The  resupply  process  begins  at  the  weapon  system 
where  ammunition  status  is  periodically  updated.  The  time 
between  updates  is  determined  based  on  draw  from  a  user 
defined  probability  distribution.  The  platoon,  for  its 
part,  periodically  updates  its  own  status  by  obtaining 
information  from  each  of  its  assigned  weapon  types.  The 
company,  in  turn,  updates  its  status  by  obtaining 
information  from  each  of  its  platoons.  The  information 
"passed"  to  each  level  is  that  obtained  from  each  entity's 
most  current  update  rather  than  from  any  source  of  "perfect" 
information.  Bequests  for  resupply  below  company  level  are 
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limited  tc  those  aaaunition  types  for  which  a  vehicle  or 
platoon  is  empty.  These  requests  alert  the  next  higher 
level  to  update  its  aaaunition  situation  and  to  take  action 
appropriate  to  its  level. 

The  formality  of  a  resupply  requisition  is 
introduced  at  company  level  where  resupply  requests  from  the 
company  to  battalion  are  triggered  every  time  a  company's 
LON  changes  for  an  aaaunition  type.  Quantities  requested 
vary  in  accordance  with  the  assets  possessed  by  the 
requesting  entity. 

3.  Imperfect .. Logistics, nation 

Information  passed  during  a  battle  is  approximate  at 
best.  The  imperfect  nature  of  this  information  is  a  rasult 
of  many  factors,  including: 

a.  Estimates  of  on-hand  ammunition  made  at  the  weapon 
during  combat  -  It  is  frequently  impossible  to  stop  and 
count  ammunition  assets  during  the  heat  of  an 
engagement;  educated  guesses  are  often  the  rule  rather 
than  the  exception  when  passing  aaaunition  information. 

b.  Time  lapses  between  resupply  requests  and  delivery  of 
requested  material  -  from  the  time  the  request  is 
forwarded  until  the  delivery  of  the  aaaunition. 
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additional  resources  will  be  expended  and  weapon 
systems  lost. 

c.  Simple  counting  mistakes. 

Within  the  model,  imperfection  of  the  logistics 
information  is  induced  as  follows: 

•  Weapon  systems  update  their  ammunition  LONs  periodically 
at  random  times  within  user  established  minimum  and 
maximum  times.  Opon  reguest  from  platoon,  the  weapon 
system  provides  its  most  current  count;  that  is,  it 
provides  the  information  obtained  from  its  own  last 
ammunition  update. 

•  Platoons  and  companies  can  obtain  their  information  only 
from  their  immediate  subordinates,  again  at  random  times 
within  user  specified  intervals.  This  procedure 
duplicates  the  periodic  reguests  for  ammunition  updates 
from  platoons  and  companies  to  their  subordinates  during 
a  battle.  Again,  the  information  reported  by  each 
subordinate  level  is  that  obtained  from  its  own  last 
update. 

•  At  the  company  level,  formal  resupply  reguests  are 
created  by  ammunition  type  as  an  ammunition's  LOH  value 
changes.  This  corresponds  to  a  company  periodically 
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reviewing  and  updating  its  resupply  requests  because  of 
ammunition  expenditures  or  loss  of  ammunition  due  to 
vehicle  damage  or  destruction.  The  quantity  reguested 
each  time  is  the  quantity  which  would  be  required  to 
bring  a  unit  back  to  full  base  load.  At  the  supply 
unit,  up*'  receipt  of  a  new  resupply  request,  this  new 
requisition  is  filed,  and  any  older  requests  for  that 
ammunition  and  that  company  are  destroyed. 

It  is  important  to  note  that  in  both  a  and  b  above 
the  modelling  techniques  described  give  the  user  the 
flexibility  to  make  the  logistics  information  flow  as 
accurate  or  inaccurate  as  desired  by  controlling  the 
randomness  of  the  LOR  updates. 

Assumptions 

The  major  assumptions  made  during  the  resupply 
request  process  are: 

a.  Requests  for  resupply  are  an  iterative  process  up  the 
chain  of  command  with  each  level  receiving  information 
only  from  its  immediate  subordinates. 

b.  An  LOR  of  empty  ("I")  initiates  an  immediate  request 
for  action  up  the  chain  of  command. 
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c.  Formal  resupply  requests  from  the  company  are  triggered 
by  changes  in  an  ammunition  LON.  The  actual  quantities 
of  ammunition  used  to  calculate  the  LON's  are  available 
at  each  level  of  command  so  that  resupply  can  be 
affected  at  that  level  if  appropriate. 

D.  RBSUPPLT 

The  resupply  process  begins  with  the  receipt  of  a 
resupply  request  by  the  Battalion  S-4.  This  receipt 
initiates  a  sequence  of  events  which  ultimately  results  in 
rounds  being  placed  on  the  weapon  system  itself.  This 
section  explains  how  resupply  of  requested  ammunition  is 
accomplished.  The  explanation  includes  modelling  the 
Battalion  S-4's  decision  logic;  the  resupply  logic  of  the 
company  after  assets  are  received  from  battalion;  and  the 
distribution  decision  logic  of  the  platoon  leader  after  a 
resupply  is  received  from  the  company.  The  explanations  are 
general  in  nature,  A  detailed  discussion  of  the  logic  is 
contained  in  Appendix  k.  Section  0. 

1 •  Battalion  Pistyj^utigti 

A  battalion’s  initial  reserve  of  ammunition  is 
determined  by  the  number  and  type  of  resupply  vehicles 
(RSVs)  in  the  support  platoon  and  the  type  and  amount  of 
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ammunition  those  vehicles  are  designated  to  carry.  This 
information  is  determined  by  the  user  and  entered  as  input. 
An  RSV's  hauling  capability  for  an  ammunition  type  is 
determined  by  its  cube  or  weight  limitations,  whichever  is 
reached  first. 

iithin  a  battalion,  the  S-4  is  responsible  for 
controlling  the  distribution  of  battalion  reserve  ammunition 
assets  to  subordinate  companies.  The  S-4's  responsibilities 
include  the  following: 

a.  Review  and  prioritization  of  reguests  filed  by  priority 
and  time  of  request.  The  most  critical  LONs  ("1")  are 
filled  first.  If  there  is  more  than  one,  the  requests 
are  filled  in  the  order  they  were  received. 

b.  Determination  of  the  number  of  RSV's  necessary  and 
available  for  resupply  missions. 

c.  Determination  of  the  proper  miz  of  ammunition  types  to 
be  delivered  to  a  unit  in  the  face  of  multiple  requests 
and  limited  transportation. 

(Jpon  the  arrival  of  a  resupply  convoy,  a  Company 
Commander  takes  the  following  actions: 
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a.  Deteraines  the  type  and  quantity  ox  the  ammunition  he 
has  received. 

b.  Deteraines  the  immediate  needs  of  the  platoons  in  the 
company. 

c.  Distributes  the  ammunition  received  to  each  platoon  in 
amounts  dictated  by  their  immediate  urgency  of  need. 

d.  Be-evaluates  the  company's  levels  of  need. 

3 •  Platoon  Distribution 

The  Platoon  Leader's  responsibilities  for  the 
distribution  of  ammunition  resupply  to  the  weapons  within 
the  platoon  are  the  same  as  those  of  the  Company  Commander. 
4.  Assumptions 

The  major  assumptions  made  in  developing  logic  to 
model  a  battalion's  ammunition  resupply  distribution  process 
are: 

a.  when  a  resupply  action  is  triggered  at  battalion,  the 
S-4  responds  only  to  those  requests  he  has  knowledge  of 
and  then  only  in  the  amounts  listed  on  that  request. 

No  further  update  is  permitted  until  a  new  request  is 
received. 

b.  BS Vs  will  not  be  dispatched  from  the  battalion  trains 
with  less  then  a  half  load  of  ammunition  unless  the 
load  contains  ammunition  with  an  LON  of  "1". 
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c.  RSV's  can  carry  loads  of  mixed  ammunition  but  only  to 
one  company. 

d.  RS¥'s  resupplying  the  same  unit  will  travel  in  convoy. 

e.  If  an  RS7  is  damaged  or  destroyed  all  the  ammunition  it 
is  carrying  is  assumed  to  be  destroyed.  The  ammunition 
is  not  replaced  during  the  simulation  run. 

f.  RSV's  that  complete  a  resupply  mission  arrive  back  at 
the  battalion  trains  with  the  same  load  they  delivered 
after  an  appropriate  time  delay.  This  simulates  the 
RSV's  round  trip  to  an  ASP/ATP  and  permits  restocking 
of  battalion  ammuniton  assets. 

g.  Ammunition  stockage  at  the  battalion  trains  is  limited 
to  the  total  weight  and  cube  limitations  of  the 
battalion  ammunition  trucks  earmarked  to  haul  it. 
Individual  RSV  loads  are  not  "fixed”  but  rather  remain 
flexible,  subject  only  to  the  stockage  at  the  trains 
and  the  weight  and  cube  restrictions  of  the  vehicle 
itself. 

h.  An  ATP/ASP  has  unlimited  supplies  of  all  ammunition 
types.  The  only  limiting  factor  on  the  amount  of 
ammunition  an  RSV  takes  back  to  its  battalion  trains  is 
the  vehicle's  own  weight  and  cube  limitation. 
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R3DISTRIBUTI0N 


T? 

M 

In  an  actual  combat  situation  redistribution  of  on-band 
aaaunition  assets  is  perforaed  as  standard  procedure  in 
certain  situations.  This  section  describes  the  situations 
which  warrant  redistribution  in  this  aodel.  It  explains 
when  and  where  the  redistributions  occur  and  the  major 
assumptions  aade  in  performing  them. 

1 .  Bedistc ibution  Due  To  Relocation 
Redistribution  takes  place  immediately  upon 

completion  of  any  unit  move.  This  activity  is  accomplished 
within  platoons  only,  with  its  objective  being  the  even 
redistribution  of  all  on-hand  assets.  In  the  model,  the 
following  actions  take  place  when  a  move  is  completed: 

a.  All  weapons  give  their  respective  platoons  an 
ammunition  update. 

b.  Each  ammunition  type  is  divided  evenly  among  weapons 
using  it  with  respect  to  the  weapon's  stowed  load. 

2.  Redistrib_qtiofl._aag_io_i_£i£epQwgr_mi 

Redistribution  of  on-hand  assets  is  perforaed  in  the 

event  of  a  vehicle  sustaining  an  F-kill.  In  this  case,  the 
platoon  redistributes  the  ammunition  as  if  it  has  just 
received  a  resupply  egual  to  the  aaaunition  on  the  F-killed 


vehicle 


3 .  Assumptions 


The  major  assumptions  made  during  a  redistribution 

are : 

a.  Redistributions  only  take  place  at  the  platoon  level. 

b.  A  vehicle  receiving  an  F-kill  becoaes  an  BSV  until  all 
on-hand  ammunition  is  distributed. 
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IV.  CONCLUDING  BgMAaKS_AgD_gOTPBE  ENHANCEMENTS 
A.  GENERAL 

This  aaaunition  resupply  model  represeats  the  first  step 
toward  the  eventual  development  of  a  low  level,  high 
resolution  logisitics  model  designed  to  interface  directly 
with  a  comparable  combat  model.  Program  logic  thus  far 
developed  explicitly  depicts  current  U.S.  Army  supply 
doctrine  at  the  battalion  level.  Beginning  with  the 
individual  firer,  the  model  simulates  the  aaaunition 
resupply  network  responding  to  identified  needs  and 
ultimately  providing  the  appropriate  ammunition  to  weapon 
systems. 

In  executing  this  process,  the  model  performs  the 
following  functions:  recognition  of  shortages  at  all  levels; 
initiation  of  requests  for  resupply  appropriate  to  the  level 
of  command;  determination  of  quantities  to  be  released  to 
fill  requests;  and  delivery  of  supplies  down  to  the  weapon 
systems.  The  authors  have  tried  to  keep  the  model  as 
flexible  as  possible  by  designing  it  in  a  manner  that  lets 
the  user  assign  values  at  input  for  the  critical  variables 
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of  the  resupply  process.  The  remainder  of  this  chapter  is 
used  to  lay  the  foundations  for  continued  work  based  on  the 
ideas  developed  in  this  thesis.  The  approach  taken  in 
outlining  the  direction  of  future  efforts  is  threefold:  to 
explicitly  highlight  some  of  the  model's  major  deficiencies; 
to  discuss  several  possible  development  paths  which  might  be 
taken  in  expanding  the  model;  and  to  discuss  adjustments 
necessary  to  integrate  this  model  with  a  comparable  low 
level,  high  resolution  battalion  combat  model. 

B.  MODEL  DEFICIENCIES 

Fundamental  to  understanding  what  a  model  can  do  is  the 
equally  important  issue  of  knowing  what  a  model  cannot  do. 
This  model  is  deficient  in  the  following  areas: 

1.  Battlefield  Realism  -  Due  to  the  simplified  nature  of 
the  battle,  combat  processes  are  not  well  played. 

Basic  forms  of  maneuver,  elementary  command  decisions, 
and  individual  combat  action  are  not  modelled  beyond 
the  simplest  levels.  These  activities  have  a 
significant  impact  on  the  supply  system  and  represent  a 
critical  deficiency  in  this  model. 

2.  Damage  Assessment  -  The  simplified  damage  assessment 
routine,  limited  to  combat  weapon  systems  only,  was 
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developed  solely  to  drive  the  resupply  logic. 

Extension  of  this  damage  logic  to  resupply  vehicles, 
development  of  a  maintenance  recovery  and  repair 
capability,  and  an  ability  within  the  supply  system  to 
respond  to  item  losses  would  be  a  significant  gain. 

3.  Movement  -  The  model  does  not  depict  movement  beyond 
the  imposition  of  a  simple  time  delay  for  travel  from 
one  section  of  the  battlefield  to  another.  These 
delays  are  based  on  doctrinal  distances  and  do  not  not 
consider  terrain,  weather,  or  suppression.  The 
addition  of  terrain  and  movement  modules  would  add  a 
significant  dimension  to  the  model  and  permit  the 
extension  of  logic  into  related  resupply  issues  such  as 
route  selection,  traffic  control,  and  traffic 
congestion. 

4.  Resupply  Logic 

a.  The  battalion  played  in  the  model  is  always 

resupplied,  after  a  time  delay,  with  the  exact  type 
and  quantity  of  ammunition  it  has  released  to  its 
companies.  The  source  of  this  resupply  is  an 
ATP/ASP  that  contains  unlimited  ammunition  assets. 
These  assumptions  significantly  reduce  the  realism 
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of  the  sodel  and  should  be  amended  to  include,  at  a 
'  minimum,  a  limit  on  the  resupply  available  to  a 

battalion  dictated  by  the  prevailing  Command  Supply 
Rata(CSR)  and  Required  Supply  Rate  (BSE) . 
b.  Convoys  in  the  model  are  limited  to  point  to  point 
delivery  of  ammunition.  Multiple  deliveries  by  one 
convoy  to  several  companies  is  not  allowed.  This 
deficiency  decreases  the  model’s  realism  by  limiting 
a  battalion’s  ability  to  efficiently  use  its 
transportation  assets,  and  a  company’s  ability  to 
control  these  assets  when  a  convoy  arrives. 

C.  PATH  OP  FUTURE  DEVELOPMENT 

Having  initiated  a  basic  structure  for  the  resupply 
model,  expansion  paths  for  resupply  logic,  both  within  the 
confines  of  the  battalion  model  itself,  and  beyond  the 
battalion  supply  point  to  brigade  have  become  apparent.  The 
expansion  ideas  mentioned  in  this  section  will  be  limited  to 
those  areas  of  improvement  within  the  supply  system  itself, 
purposely  disregarding  issues  directed  at  the  model's 
interface  with  a  high  resolution  combat  model.  Some  of  the 
points  mentioned  in  this  section  have  been  identified  as 
model  deficiencies  but  are  re-mentioned  here  for  emphasis. 

< 
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Expansion  of  this  model,  with  respect  to  resupply  logic,  is 
needed  in  the  following  areas: 

1.  Development  of  logic  to  more  realistically  depict  the 
transport  of  ammunition  from  the  ATE/ASP  to  the 
battalion  trains.  Such  logic  should  include  the 
explicit  modelling  of  supply  routes  and  the  traffic 
control  points  overseeing  these  routes. 

2.  The  effect  of  enemy  interdiction  efforts  on  the  rear 

area  supply  points. 

3.  Development  of  a  routine  to  extend  the  possibility  of 

damage  to  resupply  vehicles  and  convoys. 

4.  Development  of  routines  to  model  maintenance,  recovery, 

and  repair  as  well  as  replacement  of  damaged  systems. 

5.  Extension  of  delivery  logic  to  allow  resupply  vehicles 

and  convoys  the  option  of  delivering  to  more  than  one 
company. 

6.  Addition  of  movement  and  terrain  logic. 

7.  Improvement  of  the  redistribution  logic  to  include 

provisions  for  an  emergency  resupply  of  ammunition  if 
a  situation  warrants  it. 

8.  Explicit  representation  of  activities  at  the  ATP/ASP  to 

include  queue  and  service  times  for  trucks,  and 
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ATP/ASP  interface  procedures.  As  mentioned  in  Chapter 
2,  much  of  this  logic  has  already  been  modelled  in 
HELAPS  II  . 

9.  The  imposition  of  a  Coaaand  Supply  Hate  (CSfl)  and 

Required  Supply  Rate  (RSS)  as  a  driver  for  the  entire 
resupply  process. 

D.  INTEGRATION  INTO  A  COMBAT  MODEL 

Integration  of  this  aodel  into  a  low  level,  high 
resolution  coabat  aodel  presents  the  following  problems: 
the  problem  of  interfacing  independently  developed  program 
logic;  the  necessity  of  developing  additional  command  and 
control  logic  to  blend  the  two  models  together;  and  the  need 
to  adjust  the  tactical  decision  making  process  to  include 
the  effects  of  logistics.  Each  of  these  issues  is  discussed 
separately  below. 

The  problems  of  merging  an  independently  developed 
resupply  program  into  a  fully  developed  coabat  aodel  were 
recognized  and  carefully  considered  in  the  development  of 
this  ammunition  resupply  aodel.  To  overcome  these  problems, 
the  aodel  was  developed  as  a  self-contained  nodule.  The 
foreseeable  interface  problems  with  a  coabat  aodel  are  thus 
limited  to  insuring  that:  the  combat  aodel  captures 


ammunition  expenditures  and  passes  them  to  the  resupply 
logic;  the  resupply  model  has  movement  logic  that  interfaces 
with  the  movement  logic  of  the  combat  model;  and  the  supply 
model's  resupply  routines  interface  with  the  weapon  systems 
of  the  combat  model  when  delivering  ammunition.  Since  the 
model  developed  in  this  thesis  was  specifically  designed  to 
interface  with  the  STAS  model,  these  changes  would  be 
limited  to:  the  addition  of  several  attributes  to  the  chain 
of  command  structure;  the  addition  of  several  attributes  to 
the  weapon  systems;  and  the  integration  of  convoy  movement 
with  the  STAS  movement  logic. 

Perhaps  the  greatest  change  caused  by  the  addition  of  a 
resupply  module  would  be  its  effect  on  the  command  and 
control  logic  of  the  combat  model.  A  combat  model's 
decision  process  could  be  expanded  to  include  at  least  the 
two  most  basic  methods  of  resupply  for  a  battalion,  unit  and 
cache.  Consideration  of  these  two  methods  would  necessitate 
development  of  logic  which  could  dynamically  answer  the 
following  questions: 

1.  Who  has  priority  of  resupply? 

2.  What  ammunition  is  to  be  released  subject  to  what 
command  restrictions? 
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3.  How  will  resupply  be  accomplished?  Hill  supply 
personnel  be  present  with  any  type  of  equipment? 

4.  Where  will  the  resupply  be  accomplished?  &t  the  current 
location?  At  a  subsequent  position?  At  a  rendezvous 
point? 

Lastly,  combat  decisions  are  inevitably  influenced  by 
the  availability  or  nonavailability  of  resupply,  inclusion 
of  resupply  logic  into  a  combat  model  would  force  an  active 
consideration  of  resupply  issues  in  making  the  following 
tactical  decisions: 

a.  Adjusting  rates  of  fire. 

b.  Changing  a  weapon’s  primary  ammunition  of 
engagement. 

c.  Decreasing  or  increasing  a  weapon's  range  of 
detection  and  engagement. 

d.  Movement  to  alternate  positions  or  the  withdrawal  of 
a  unit. 
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DETAILED  METHODOLOGY  OF  THE  MODEL 

A.  IN  TROD  OCT  ION 

This  appendix  gives  a  detailed  description  of  the 
ammunition  resupply  aodel  in  a  format  suitable  for  use  by 
programmers  and  analysts.  The  discussion  in  this  appendix 
approaches  the  model  from  a  broad  perspective  in  order  to 
show  the  effect  of  the  techniques  used  to  aodel  the  "real 
world"  resupply  process.  Prior  to  discussing  the 
methodology  itself,  a  brief  description  of  the  SIMSCRIPT 
II. 5  programming  language  used  in  the  aodel  is  provided  for 
readers  unfamiliar  with  the  language.  A  detailed 
explanation  of  the  actual  code  developed  is  provided  in 
Appendix  B. 

B.  USE  OP  SIMSCRIPT  II. 5  IN  THE  HODEL 

The  SIMSCRIPT  II. 5  programming  language  is  designed  to 
model  discrete-event  simulations.  It  is  a  user  friendly 
language  with  a  structure  very  similar  to  everyday  speech. 
This  feature  enables  a  reader  to  quickly  grasp  and  follow 
the  flow  of  any  program.  Beyond  the  narrative  clarity. 


SIMSCRIPT  provides  an  organizational  structure  which  extends 
a  programmers  conceptual  horizon  beyond  the  normal  bounds 
imposed  by  the  use  of  variables  and  arrays.  Central  to  this 
structure  are  the  key  ideas  of  entities,  attributes,  and 
sets. 

Entities  are  program  elements  whose  characteristics  are 
being  modelled  in  the  simulation.  In  the  ammunition 
resupply  model  for  example,  tanks,  platoon  leaders,  company 
commanders  and  supply  officers  are  classes  of  entities  in 
the  system.  Attributes  are  discriptors  which  depict  the 
entity's  characteristics.  In  the  model,  every  platoon 
leader  entity  carries  attributes  which  define  his  unique 
company  commander.  Thus,  although  all  entities  in  the  same 
class  have  the  same  attribute  names,  they  can  be 
distinguished  from  each  other  by  the  values  of  their 
attributes.  Attributes  may  have  real,  integer,  or 
alphanumeric  values. 

A  set  is  a  collection  of  entities  possessing  some  common 
property.  The  ammunition  resupply  model  uses  sets  to  track 
the  type  and  amount  of  ammunition  on-hand  in  each  platoon. 
This  is  done  by  creating  an  entity  for  each  type  of 
ammunition  with  attributes  which  record  the  quantity 
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required  and  actually  on-hand.  Each  entity  is  then  filed  in 
a  platoon's  ammunition  set  and  its  attributes  thereafter 
track  only  that  platoon's  aaaunition  status. 

&n  event  in  SIMSC8IPT  is  an  occurrence  vhich  takes  place 
at  a  specific  simulated  tise.  Events  can  change  the  values 
of  entity  attributes,  remove  or  add  entities  to  sets,  create 
or  destroy  entities,  or  schedule  other  events  to  take  place 
at  later  times.  In  the  model,  a  weapon  which  expends  all  of 
its  ammunition  keys  an  event  which  notifies  the  platoon 
leader  and  starts  decision  logic  for  resupply.  Events  take 
place  instantaneously  and  do  not  consume  simulated  time. 

The  use  of  SIMSCBIPT  II. 5  greatly  simplifies  the 
tracking  of  aaaunition  expenditures  throughout  the  chain  of 
command.  The  actual  set,  entity,  and  attribute  structure 
used  in  this  model  is  explained  in  detail  in  Appendix  B. 

C.  GENERAL  MODEL  METHODOLOGY 

The  aaaunition  resupply  model  developed  for  this  thesis 
is  a  stochastic  discrete-event  simulation  designed  to 
portray  ammunition  resupply  procedures  within  a  U.S.  combat 
battalion.  The  model  is  a  stand-alone,  closed  loop  process 
which  simulates  the  following  activities  within  a  combat 
battalion:  periodic  updating  of  individual  weapon  and  unit 
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aaaunition  status;  recognition  of  the  teed  for  and 
subaission  of  requests  for  resupply;  and  receipt  and  issue 
of  supplies  froa  battalion  reserve  stocks.  The  overall 
process  Modelled  is  depicted  in  Figure  2  below. 


Figure  2:  Resupply  Process 


The  fundamental  process  depicted  in  the  figure  is  duplicated 
at  all  levels  of  cos sand  (weapon#  platoon#  cospany#  and 
battalion) ,  differing  only  in  the  response  options  available 
at  each  level. 

0.  INPUT  BSQUIBESENTS  AND  THE  INITIALIZATION  OF  DATA  ABB A IS 
Input  to  the  aodel  is  used  to  accoaplish  the  following: 
the  creation  of  entities  played  in  the  siaulation;  the 

i 

establishaent  of  chain  of  coaaand  relationships  between 
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entities;  the  scheduling  of  initial  ammunition  update  times; 
and  the  establishment  of  parameter  values  for  supply  action 
and  response (LON  Thresholds).  This  initialization  process 
is  controlled  by  routine  BLU .CREATE,  which  creates  the  major 
entities  played  and  calls,  in  turn,  routine  BASIC. LOAD  to 
establish  initial  ammunition  loads,  and  routine  PARAHETERS 
to  initialize  the  critical  data  arrays  and  global  variables. 

1 •  Generating  Resupply  Requirements  -  The  Battle 
Generation  of  requirements  to  exercise  the 
ammunition  resupply  model  was  initially  to  have  been 
accomplished  through  interaction  with  the  low  level,  high 
resolution  STAR  combat  model.  However,  attempts  to  utilize 
the  STAR  battle  in  its  current  configuration  led  to 
difficulties  with  the  pace  of  battle  problem  previously 
discussed  in  Chapter  1  and  the  objective  was  abandonned,  at 
least  for  this  thesis  effort.  In  lieu  of  this,  a  simplified 
battle  was  developed  strictly  to  generate  requirements  for 
the  model.  It  must  be  emphasized  that  significant 
conclusions  cannot  be  drawn  from  the  battle  summaries 
produced  by  this  model.  The  sole  function  of  the  battle 
designed  is  to  generate  requirements  in  order  to  exercise 
the  model's  resupply  logic.  The  requirements  generated  for 
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'■he  model  can  be  grouped  into  three  broad  catagories: 
ammunition  expenditures,  damage  and  destruction  of  combat 
vehicles,  and  unit  movement.  The  following  paragraphs 
explain  how  the  information  generated  is  used  in  the  model, 
a.  Ammunition  Expenditures 

Ammunition  expenditures  take  place  only  during 
scheduled  battle  periods.  These  periods  are  randomly 
scheduled  for  six  hours  a  day  by  the  event  BAT. L. TIME. 
Assessment  of  the  quantities  of  ammunition  fired  by  each 
weapon  is  determined  in  routine  BATTLE  which  is  called  by 
each  weapon  system  when  it  updates  its  ammunition  status.  In 
execution,  routine  BATTLE  performs  the  following  functions: 

(1)  checks  if  a  battle  is  in  progress  -  This  is  simply  a 
check  if  the  emulation  time,  TIME. v,  is  greater  than 
the  battle  starting  time,  B.STABT,  and  less  than  the 
battle's  end  time,  B.EHD.  If  it  is  outside  this  limit, 
there  is  no  active  on-going  battle  and  the  routine 
returns  without  action. 

(2)  Determines  if  a  weapon  fires  -  A  check  is  made  on  each 
of  six  possible  weapons  carried  by  a  weapon  system  to 
see  if  they  have  fired.  This  is  accomplished  by 
comparing  successive  random  number  draws  against  a 


probability  of  firing  for  each  ammunition  owned  by  the 
weapon  system.  If  the  random  number  drawn  is  less 
than  the  assigned  probability  of  fire,  the  ammunition 
being  tested  has  fired,  and  expenditures  are  computed. 
If  not,  no  expenditures  are  computed  and  the  logic 
transfers  to  the  next  ammunition  carried  on  the  weapon 
system. 

(3)  Expends  Ammunition  -  Each  of  the  six  ammunition  types 
carried  by  a  weapon  system  is  assigned  a  unique  rate 
of  fire.  This  rate  of  fire  is  stored  in  an  array, 

ROF,  which  is  input  in  routine  PABAHETEBS.  If  the 
determination  is  made  that  an  ammunition  has  been 
fired,  the  quantity  expended  is  computed  through  the 
use  of  an  exponential  function.  Lambda  for  the 
function  is  set  egual  to  the  ammunition  rate  of  fire 
and  the  exponent  is  completed  by  multiplying  this 
lambda  times  the  elapsed  battle  time.  This  Technique 
inevitably  causes  a  greater  expenditure  of  rounds  as 
the  battle  time  increases,  however,  its  overall  effect 
on  the  running  of  the  model  is  negligible. 
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b.  7ehicle/Weapon  Damage  and  Destruction 

Logic  depicting  the  damage  and  destruction  of 
vehicles  and  weapons  was  added  in  order  to  exercise  the 
model's  capability  to  adjust  for  ammunition  assets  lost 
throughout  the  battle.  Losses  and  damage  are  generated  only 
for  combat  weapon  systems.  supply  systems  are  not  subject 
to  combat  loss  or  damage. 

The  modelling  of  vehicle/weapon  damage  and 
destruction  is  done  in  routine  BATTLE  with  assessment  of 
loss  or  damage  limited  to  the  6  hour  battle  period.  There 
are  four  types  of  damage  played,  K-kill,  F-kill,  H/F-kill, 
and  K- kill .  Probabilities  for  each  type  of  damage  are 
weapon  system  unique  and  obtained  from  an  array, 

POD  (Probability  of  Damage),  input  in  routine  PARAHETERS. 
Assessment  of  damage  is  accomplished  by  drawing  a  separate 
random  number  against  each  probable  type  of  damage.  If  the 
number  drawn  is  less  than  the  probability  for  the  type  of 
damage  being  reviewed,  the  weapon  sustains  the  damage.  This 
technique  leaves  open  the  possibility  that  a  weapon  may 
sustain  multiple  types  of  damage,  however,  this  side-effect 
is  of  little  importance  to  the  model's  execution. 
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c.  Uni'1:  Moves 

The  possibility  of  a  company  relocating  during 
the  simulation  was  incorporated  in  order  to  exercise 
redistribution  logic  contained  in  the  supply  model.  The 
assumption  underlying  the  need  for  the  inclusion  of  this 
logic  is  that  tactical  units  will  seek  to  redistribute 
ammunition  either  before  or  after  displacement  in  order  to 
achieve  an  ammunition  balance  among  its  weapon  systems.  The 
execution  of  a  unit  move  within  this  model  in  no  way  affects 
the  conduct  of  the  remainder  of  the  battle.  Unit  moves  are 
scheduled  randomly  in  event  BIT. L. TIME  at  the  start  of  each 
6  hour  battle.  Redistribution  of  company  assets  is 
accomplished  upon  completion  of  a  move  within  each  of  the 
company's  plat  cons.  Cross-leveling  of  ammunition  between 
platoons  is  not  modelled.  In  execution,  each  company  draws 
a  uniform  (0,1)  random  number,  and,  if  that  number  is  less 
than  a  user  designated  probability  of  move,  the  company  will 
move  at  the  end  of  the  battle. 
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The  determination  of  Level  of  Need  is  performed 
independently  and  at  random  intervals  for  every  weapon 
system,  platoon,  and  company  played  in  the  simulation.  The 
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purpose  of  an  LON  is  tc  provide  an  indication  of  the  urgency 
of  need  an  element  has  for  each  of  the  anaunition  types  it 
possesses.  A  distinct  LON  value  is  cooputed  at  each  level 
of  coaaand.  This  aodels  the  increasingly  wider  perspective 
of  the  battle  taken  by  coaaanders  further  up  the  chain  of 
command.  The  net  effect  of  this  technigue  is  to  limit  the 
importance  of  any  one  ammunition  type  as  it  is  factored 
against  other  ammunitions  played.  The  following  subsections 
fully  discuss  the  details  of  the  process  just  described, 
a.  Imperfect  Information 

As  discussed  in  Section  C,  Chapter  3, 
information  in  a  logistics  network  is  approximate  at  best. 

In  the  model,  this  imperfection  is  achieved  by  randomizing 
the  times  at  which  ammunition  updates  occur  at  each  level 
and  by  limiting  the  knowledge  passed  from  one  level  to 
another  to  that  obtained  in  the  most  recent  update.  The 
following  example  illustrates  the  effect  of  this  technigue. 

A  tank  updates  its  ammunition  status  10  minutes  into  the 
battle  and  finds  40  HE  rounds  on-board.  At  30  minutes  into 
the  battle  the  tank  has  30  rounds  remaining.  At  this  point, 
the  platoon  leader  conducts  an  update  and  is  informed  that 
the  tank  has  40  rounds  on-board.  The  platoon  leader  then 
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bases  his  decisions  on  this  iaperfection  information. 

Similar  update  processes  are  perforaed  at  each  level  of 
command  with  the  information  provided  forming  the  basis  of 
LON  computations  at  that  level.  The  degree  of  iaperfection 
in  the  inforaation  passed  depends  on  the  length  of  time 
between  updates.  These  time  intervals  are  entered  by  the 
user  as  input  in  routine  PAHAMETBS. 

b.  Initial  Assets  and  Capacities 

The  initial  ammunition  assets  of  each  weapon  and 
resupply  vehicle  are  input  by  the  user  in  routine  BLO. CHEATS 
as  the  teaporary  attributes  OH1  through  0H6.  The  number  of 
ammunition  types  that  can  be  played  in  the  model  is 
unlimited;  however,  the  guantity  of  each  ammunition  type  on 
board  a  weapon  system  is  liaited  to  a  maximum  stowed  load 
figure.  Naxiaua  values  are  set  for  each  ammunition  type  and 
carried  as  the  attributes,  SLO ADI  through  SL0AD6,  on  every 
weapon  system.  The  stowed  load  configuration  on  a  weapon 
systea  represents  the  users  assessaent  both  of  what  should 
be  and  what  can  be  carried  on  a  weapon  system.  This 
configuration  is  unigue  to  each  combat  weapon  system  entity. 

The  platoon  and  company  eguivalent  of  a  stowed 
load  for  an  ammunition  type  is  called  the  base  load  for  an 


ammunition  type.  Base  loads  for  an  ammunition  type  are 
computed  by  summing  over  the  stowed  loads  carried  on  all 
undamaged  elements  within  a  unit, 
c.  Weapon  LON's 

weapon  systems  form  the  basis  for  all  LON 
calculations  in  the  model  since  it  is  at  the  weapon  level 
that  ammunition  is  expended.  Levels  of  need  vor  a  weapon 
system  are  computed  in  routine  R.AMMO  for  each  of  the  six 
possible  ammunition  types  a  weapon  system  might  possess. 
Routine  R.  AHHO  calls  routine  BATTLE  to  generate  ammunition 
expenditures,  and  based  on  these  expenditures,  R . ANNO 
updates  a  systems  knowledge  of  its  current  ammunition 
status.  R.AMMO  is  called  from  several  events  for  different 
purposes. 

Event  OP. R.AMMO  calls  routine  R.  ANNO  randomly 
throughout  the  simulation  in  order  to  model  a  weapon 
system's  crew  periodically  checking  its  on-hand  resources. 
UP. R.AMMO  is  scheduled  individually  for  each  weapon  system 
played  based  on  successive  draws  from  a  uniform 
distribution.  The  delimiting  times  for  the  distribution, 
WHIN  and  RHAZ,  are  input  by  the  user  in  routine  PARAHSTERS. 
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The  event  is  repeatedly  re-scheduled  throughout  the 

■k 

1  simulation  unless  the  weapon  updating  sustains  some  battle 

damage. 

Events  CO. BESUPPL7 . ABE,  REDISTRIBUTE,  and 
FIREKILL  call  routine  K.AMBO  fox  all  undamaged  weapon 
systems  within  a  unit  in  order  to  obtain  an  immediate  update 
of  the  current  situation  prior  to  executing  their  respective 
program  segments.  These  calls  simulate  a  weapon  system's 
crew  checking  its  on-hand  resources  prior  to  any  resupply 
action . 

The  actual  calculation  of  an  LON  for  an 
ammunition  type  is  accomplished  by  taking  the  on-hand 
ammunition  of  an  undamaged  weapon  and  dividing  it  by  the 
authorized  stowed  load  of  that  ammunition  for  that  weapon. 
The  resulting  percentage  is  compared  to  the  weapon  system 
threshold  values  stored  in  the  array  NPNLON  which  is 
initially  input  in  routine  PARAMETERS.  The  threshold  values 
contained  in  the  array  mark  the  lower  boundaries  of  LON 
catagories.  Figure  3  is  an  example  of  an  LON  calculation 
for  APDS  ammunition  on  board  a  tank. 


{ 
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System  type  -  Tank 

Wpn  type  -Hi 

*  =  on-hand  /  stowed  load 

Ammo  type  -  APDS 

*20/40 

On-hand  -  20  rounds 

*  .5 

Stowed  Load  -  40  rounds 

WLON  THBESHOLDS  (TANK  .APDS) 

"5"  k  .85 

"4"  k  .60 

"3"  k  .40 

"2"  k  .15 

"1«  2;  0.0 

Therefore  since  .60  2:  .50  2: 

HPLON  =  "3" 

.40  j 

_ 

Figure  3;  Weapon  LON  Example 


d.  Platoon  LON 

Platoon  LON  inforaation  is  updated  in  the 
routine  P. CLASS.?.  The  process  performed  in  this  routine  is 
essen*ially  a  suaeation  of  the  inforaation  carried  on-board 
the  undaaaged  weapons  in  the  platoon.  This  process  updates 
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both  the  platoon’s  current  on-hand  information,  and  the  base 
load  information  for  that  ammo  type.  As  each  aaaunition  is 
updated,  a  platoon  percent  fill  is  calculated  for  each 
ammunition  type  by  dividing  the  current  on-hand  quantity  of 
an  ammunition  by  its  current  base  load  in  that  platoon.  The 
percent  fill  calculated  is  compared  to  the  platoon  LON 
threshold  values  for  that  ammunition  type.  These  critical 
values  are  stored  in  the  array  PLTLON  which  is  input  in  the 
routine  PARAMETERS.  The  threshold  values  contained  in  the 
array  mark  the  lower  boundaries  of  the  Ion  categories. 

P. CLASS. V  is  called  by  several  events  for  different 
purposes. 

Event  OP.PLT.ABBO  calls  routine  P. CLASS. V 
randomly  throughout  the  simulation  in  order  to  model  a 
platoon  leader  periodically  checking  the  platoon's  on-hand 
resources.  OP.PLT.ABBO  is  scheduled  individually  for  each 
weapon  system  played  based  on  successive  draws  from  a 
uniform  distribution.  The  delimiting  times  for  the 
distribution,  PMIN  and  PBAX,  are  input  by  the  user  in 
routine  PARAMETERS.  The  event  is  repeatedly  re-scheduled 
throughout  the  simulation  unless  all  weapons  in  the  platoon 
sustain  damage  and  can  no  longer  use  ammunition. 
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Events  CO. RESUPPLY. ARB,  REDISTRIBUTE ,  and 
FiREKILL  call  routine  P. CLASS. V  for  all  platoons  within  a 
unit  in  order  to  obtain  an  immediate  update  of  the  current 
situation  prior  to  executing  their  respective  program 
segments.  These  calls  simulate  a  platoon  leader  checking 
the  unit's  resources  prior  to  any  resupply  action. 

Figure  4  is  an  example  of  how  a  platoon  LON  is 
calculated.  It  is  important  to  note  in  the  example  that  the 
stowed  load  and  on-hand  ammunition  of  the  3rd  tank  is  not 
considered  because  the  tank  is  an  M-kill.  Also,  the  stowed 
load  of  tank  2  is  disregarded  because  the  weapon  can  no 
longer  fire  since  it  has  been  F-killed.  The  on-hand 
ammunition  of  tank  2  is  not  dropped  from  the  computation 
however,  due  to  the  fact  that  the  tank  is  still  mobile  and 
can  be  used  as  a  resupply  vehicle  to  deliver  ammunition  to 
other  systems  in  the  platoon, 
e.  Company  LON 

Company  LON  values  are  computed  and  assigned  in 
routine  COM. AMMO.  In  evaluation  of  this  LON,  the  first  step 
performed  is  to  sum  over  all  assigned  platoons  in  order  to 
update  the  company's  on-hand  and  base  load  information. 
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SYSTEM 

HPN 

AMMO 

STONED  LOAD 

ON 

l-HAND 

STATUS 

(1) 

Tank 

Ml 

AP 

40  rounds 

20 

rounds 

Alive 

(2) 

Tank 

Ml 

AP 

40  rounds 

15 

rounds 

F-kill 

(3) 

Tank 

Ml 

AP 

40  rounds 

30 

rounds 

M-kill 

(4) 

Tank 

Ml 

AP 

40  rounds 

25 

rounds 

Alive 

PIT  ION  THRESHOLDS  <APDS) 
"5"  >  .90 
"4"  2  .65 
"3"  >  .45 
"2''  >  .20 
"1"  >  0.0 


%  »  Tot  Pit  on-hand  aaao(AP)  /  Sua  Npn  stowed  loads  (AP) 
=  60/80  =  .75 

Therefore  since  .90  2  .75  2  .65 
PLTLON  *  ”4" 


Figure  4:  Platoon  LON  Example 


A  percent  fill  value  is  then  computed  by  dividing  the 
on-hand  quantity  for  each  aaaunition  by  the  required  base 
load  for  that  aaaunition.  This  percent  fill  is  then  coapared 
to  coapany  LON  threshold  values  stored  in  the  KPNLON  array 
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which  is  input  initially  in  the  routine  PARAMETERS.  The 
threshold  values  contained  in  this  array  mark  the  lower 
boundaries  of  the  LON  values.  CON. AMMO  is  called  by  several 
events  for  different  purposes. 

Event  OP . COM. ANNO  calls  routine  c CM. AMMO 
randomly  throughout  the  simulation  in  order  to  model  a 
company  commander  periodically  checking  the  platoon’s 
on-hand  resources.  OP. COM. AMMO  is  scheduled  individually 
for  each  weapon  system  played  based  on  successive  draws  from 
a  uniform  distribution.  The  delimiting  times  for  the 
distribution,  CHIN  and  CMAX,  are  input  by  the  user  in 
routine  PARAMETERS.  The  event  is  repeatedly  re-scheduled 
throughout  the  simulation  unless  all  weapons  in  the  company 
sustain  damage  and  can  no  longer  use  the  ammunition. 

Events  CO. RESUPPLY .ARB,  REDISTRIBUTE ,  and 
FIREKILL  call  routine  COM. AMMO  for  the  company  receiving 
resupply  in  order  to  obtain  an  immediate  update  of  the 
current  situation  prior  to  executing  their  respective 
program  segments.  These  calls  simulate  a  company  commander 
checking  the  unit's  resources  prior  to  any  resupply  action. 

Figure  5  gives  an  example  of  how  a  company  LON 
is  calculated  for  APDS  ammunition.  •  In  this  example  the 
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first  platoon  data  is  taken  from  the  platoon  ION  example 
given  in  Figure  4.  The  company  example  depicts  2nd  platoon 
having  4  Ml  tanks,  each  tank  with  a  stowed  load  of  40  AP 
rounds  and  total  platoon  cn-hand  assets  of  80  AP  rounds. 


PLT 

SYSTEM 

HPN 

AMMO 

STONED  LOAD 

ON-HAND 

1 

tank 

Ml 

AP 

80 

60 

2 

tank 

Ml 

AP 

160 

80 

3 

tank 

Ml 

AP 

80 

20 

COMPANY  LON  THBESHOLDS  (AP) 

"5"  >  .85 
"4"  2  .60 
”3"  >  .40 
”2"  2  .20 
H  1 M  >  0.0 

Percent  -  Tot  Co.  on-hand  Ammo  /  Sum  of  Pit  stowed  loads 
=  160  /  320 
=  .5 

Therefore  since  .60  2  .50  >  .40 
COMLON  =  "3" 


Pigure  5:  Company  LON  Example 
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In  a  similar  manner  it  can  be  seen  that  the  3rd  platoon  has 
2  81  tanks  remaining  with  20  AP  rounds  between  them  and  a 
stowed  load  of  80  rounds,  20  per  tank. 

3.  Bequests  for  Resupply 

Resupply  requests  are  made  by  a  company  and  sent  to 
the  battalion's  S-4  based  on  the  information  passed  up  the 
chain  of  command  from  the  individual  weapon  systems  through 
the  subordinate  platoons.  Within  the  model  logic,  the 
periodic  updating  of  ION  information  up  to  company  level  is 
the  key  to  transmission  of  these  resupply  needs.  Beyond  the 
company  level  a  requisition  processing  system  replaces  the 
LON  concept.  Prior  to  the  submission  of  a  "formal'' 
requisition  by  the  company  to  the  S- 4,  several  informal 
actions  that  take  place  which  key  the  submission  of  a 
requisition  for  a  particular  ammunition  type.  These  actions 
occur  at  the  weapon,  platoon,  and  company  levels.  This 
section  explains  this  informal  process  which  results  in  the 
Battalion  S-4  receiving  a  valid  requisition  from  the 
company. 

a.  Weapon  Systems 

Weapon  systems  do  not  request  ammunition 
resupply;  they  simply  p*ss  their  most  current  knowledge  to 
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■the  platoon  at  the  time  a  platoon  check  is  Bade.  In  the 
event  that  a  weapon  system  exhausts  its  supply  of  an 
aaaunition  type,  an  immediate  scheduling  of  the  event 
OP . PLT . Aflfio  is  made.  This  logic  simulates  a  weapon  systea 
informing  its  platoon  leader  of  the  situation,  and  the 
platoon  leader,  in  turn,  performing  a  quick  check  of  the 
rest  of  the  platoon  to  see  how  extensive  the  problem  is. 

b.  Platoon 

Platoons  do  not  request  resupply;  they 
periodically  check  all  subordinate  systems  and  pass  on 
information  for  each  ammunition  type  to  the  company  when  the 
company  checks  on  its  ammunition  status.  In  the  event  that 
a  platoon  exhausts  its  supply  of  an  ammunition  type,  an 
immediate  scheduling  of  the  event  OP.COfl.AHiiO  is  made.  This 
logic  simulates  a  platoon  leader  informing  the  unit's 
company  commander  of  the  situation,  and  the  company 
commander,  in  turn,  performing  a  quick  check  of  the  rest  of 
the  company  to  see  how  extensive  the  problem  is. 

c.  Company 

The  company  is  the  first  level  of  command 
permitted  to  create  and  submit  resupply  requisitions  in 
order  to  correct  deficiencies  in  a  unit's  ammunition 
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posture,  within  routine  CO.AHHO,  changes  in  the  Level  of 
Need  computed  for  an  aaaunition  type  trigger  the  creation  of 
a  resupply  request,  RES. HEQ,  for  that  specific  aaaunition 
type.  These  requests  are  transaitted  to  battalion  supply  by 
scheduling  the  event  ap.S4.AdHO  and  passing  the  coapany's 
requisition  list  as  an  arguaent  to  battalion.  The  scheduled 
tiae  of  arrival  for  the  request  is  deterained  by  drawing  a 
randoa  nuaber  froa  a  uniform  distribution.  The  delimiting 
times  for  use  in  the  distribution,  HINTRXP  and  HAXTRIP,  are 
input  in  routine  PARAHETERS.  Use  of  this  distribution  to 
schedule  the  event  tiae  models  the  delay  caused  by  the 
necessity  to  physically  carry  the  requests  to  the  supply 
point. 

d.  Battalion 

For  the  purposes  of  this  model,  a  battalion  does 
not  submit  requests  for  resupply.  Convoys  returning  from  a 
company  resupply  mission  are  assumed  to  have  been  reloaded 
at  the  ASP/ATP  with  exactly  the  same  quantity  of  ammunition 
they  had  just  delivered  to  a  company.  In  this  way, 
battalion  stocks  are  constantly  refilled. 
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4. 


Storage  and  issue  of  a  battalion's  reserve 
aaaunition  is  simulated  in  event  UP. S4.AHH0.  The  purpose  of 
UP.S4.AMH0  is  to  nodel  the  actions  of  a  battalion  S-4 
officer  allocating  his  liaited  aaaunition  and  transportation 
assets  in  response  to  reguests  froa  the  supported  units. 

The  event  is  scheduled  in  routine  CO&.AttHO  when  a  resupply 
request  is  created.  Functionally*  the  routine  accoaplishes 
these  actions  through  evaluation  of  the  following 
considerations:  the  availability  of  supply  and 
transportation  assets;  the  need  to  aaxiaize  the  use  of 
shipping  space  on  board  resupply  vehicles;  the  need  to 
adjust  shipments  in  the  face  of  priority  requests;  and 
control  of  the  dispatch  of  resupply  convoys.  The 
subsections  which  follow  discuss  each  of  these 
considerations.  Significantly,  in  the  prograa  logic  as  it 
exists,  resupply  convoys  are  Halted  to  one  stop  deliveries. 
Multiple  unit  deliveries  are  not  peraitted. 

a.  Availability  of  Supply  and  Transportation  Assets 
Stock  acccuntability  of  aaaunition  is  aaintained 
for  each  CLASS  V (aaaunition)  itea  belonging  to  a  supply 
officer  in  a  teaporary  enttiy  SCL.V.ITEH.  Besupply  requests 
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to  the  S-4  are  matched  against  the  on-hand  balance  in  this 
temporary  entity  to  determine  if  the  supplies  are  available 
for  release,  k  concurrent  determination  of  the  availability 
of  transportation  assets  is  made  through  a  comparison  of  the 
total  weight  and  cube  available  on  resupply  vehicles  for 
shipping  and  the  total  weight  and  cube  reguested. 

b.  Maximization  of  Shipping  Space 

Program  logic  allows  more  than  one  type  of 
ammunition  to  be  loaded  on  a  single  truck.  This  models  the 
S-4  seeking  to  effectively  utilize  the  limited  resources  at 
his  disposal.  The  identity  of  ammunition  stocks  released  to 
fill  a  reguest  is  modelled  through  the  creation  of  a 
temporary  entity,  T.CGO.  This  level  of  detail  permits  a 
determination  of  the  total  cargo  manifest  loaded  on  any 
individual  truck. 

c.  Adjustments  Due  to  Priority  Beguisitions 

k  key  assumption  modelled  in  the  program  is  that 
a  unit  commander  will  order  the  guantity  of  supplies 
necessary  to  refill  the  unit's  base  load  for  an  ammunition 
type,  ka  such,  in  the  face  of  multiple  priority  1  and 
priority  2  requisitions  and  limited  transportation  assets, 
program  logic  models  an  S-4  decision  to  reduce  fill  on 
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individual  requisitions  in  order  to  permit  a  greater  nuaber 
of  requisitions  to  be  filled.  This  reduction  in  fill  is 
flexible  subject  only  to  the  aaxiaum  lower  bounds  C. L1.PCT 
(CRITICAL  LON  1  PERCENT)  and  C . L2. PCI (CRITICAL  LON  2 
PERCENT) .  These  deliaiters  are  input  in  routine  PARAMETERS. 

E.  RBSOPPLT  ACTIVITIES  -  RECEIPT  OF  SUPPLIES 

The  transport  of  supplies  to  fill  requisitions  basically 
follows  the  reverse  path  of  the  requisition  flow.  This  is  to 
say  that  supplies  are  issued  through  the  chain  of  coaaand 
back  to  the  weapon  systeas.  At  each  level  of  coaaand,  new 
decisions  are  Bade  as  to  the  apportionment  of  the  supplies 
to  subordinate  levels  based  on  the  aost  current  information 
available.  In  executing  the  applicable  routines  modelling 
this  process  the  first  step  performed  is  an  update  of  the 
aaaunition  status  of  all  levels.  The  apportionment  process 
itself  involves  the  repetitive  computation  at  each  level  of 
a  ratio  (subordinate  need  /  total  unit  need)  times  the 
quantity  delivered.  The  pattern  for  this  process  is  set  in 
event  CO. RESUPPLY. ARRIVE.  This  event  is  scheduled  to  mark 
the  arrival  of  a  resupply  convoy  at  a  company  unit. 
Additionally,  two  other  instances  involving  a  similar 
reapportionment  of  ammunition  were  included  in  the  model. 
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These  are  PIREKILL  and  REDISTRIBUTE.  Event  PIREKILL  nodels 


a  platoon  leader's  decision  to  distribute  the  aaaunition 
assets  froa  non-functional  weapon  systens  to  the  reaainder 
of  the  platoon.  Event  REDISTRIBUTE  aodels  an  assuaed 
standard  operating  procedure  that  requires  platoons  to 
cross-level  aaaunition  assets  between  weapons  after  a  unit 
aove  is  executed.  This  routine  differs  froa  the  two  previous 
in  that  the  basis  for  distribution  of  the  assets  is  the 
ratio  of  the  weapon  systea's  stowed  load  to  the  platoon's 
base  load  tines  the  total  quantity  required  for  the  platoon. 


APPENDIX  B 


PROGRAM  DOC 0 MENTATION 

This  appendix  provides  a  detailed  explanation  of  the 
code  developed  for  the  aaaunition  resupply  model.  Por  this 
discussion,  the  model  has  been  broken  out  into  its  aajor 
routines  and  events  with  each  being  discussed  separately. 

The  PREAMBLE  section  contains  a  detailed  definition  of  every 
entity,  attribute,  set,  and  global  variable  used  in  the 
prograa.  Thereafter,  discussion  of  routines  and  events 
includes:  an  abbreviated  glossary  of  ter as,  a  listing  of  the 
prograa  code,  and  a  line  by  line  description  of  the  code. 

All  definitions  within  a  section  are  grouped  by  their 
SIMSCRIPT  category  then  listed  alphabetically.  If  an 
abbreviation  is  unclear  an  unabbreviated  naae  is  given  in 
parentheses  beside  it. 


A.  "PREAMBLE" 


The  preaable  provides  the  compiler  with 
regarding:  entities,  attributes,  and  sets; 
routines;  global  variables  and  arrays.  Many 
descriptors  used  in  this  preaable  are  taken 


definitions 
events  and 
of  the 

directly  fora 
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the  current  STAR  model.  Those  taken  directly  from  STAS  are 
redefined  here  for  clarity  purposes  and  can  be  identified  by 
an  asterisk  (*)  . 

1.  tegiiMS 

The  routines  of  this  model  are  described  in  detail 

in  sections  C  through  N  of  this  appendix.  The  routines  used 

are  as  follows: 

BLO. CREATE 
BASIC. LOAD 
P. CLASS . V 
BATTLE 

FILE. OP. DATE 
NT.  AND.  COBE 

2.  Evqnts 

The  events  for  this  model  are  explained  in  detail  in 
sections  N  through  Z  of  this  appendix.  The  events  of  the 
model  are: 


PAHAMETEBS 
W . AMMO 
COM. AMMO 
OP.  DATE 

LOAD. THE. TB OCRS 
PBI . BESOPPLI 


B.  OP.  DATE 
PIREKILL 
CO. BESOPPLI. AB 
OP. S4. AMMO 
STOP. SI EOLATION 
OP.PLT. AHHO 


BAT. L. TIME 
BN. ABHIVE 
HOVE 

BEDISTBIBUTE 
OP.  COM.  A  MHO 
OP. W. AMMO 
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3 .  Entities 

The  entities  of  any  SIliSCRIPT  program  are  either 
permanent,  meaning  they  remain  active  throughout  the 
program's  execution,  or  temporary,  meaning  they  can  be 
created  or  destroyed  during  program  execution.  Definitions 
of  both  type  of  entities  are  listed  below. 

Permanent  Entities 

COMPANY. COMMANDER  (rt) .  Used  to  model  the  company  commander's 
thought  process.  Owns  sets  containing  the  unit's 
platoons (CO. UNIT  composed  of  PLATOON .LEADERS)  and  the 
unit's  unique  ammunition  listing  (CO. AMMO  composed  of 
CCL.Y. ITEMS) . 

PLATOON. LEADER (*) .  Used  to  model  the  platoon  leader's 

thought  process.  Owns  sets  containing  the  unit's  weapon 
systems (PLAT. UNIT  composed  of  TANKS)  and  the  unit's 
ammunition  listing  (PLT.AMMO  composed  of  PCL . V. ITEMS)  . 
SUPPLY. OFPICER.  Used  tc  model  a  battalion  supply  officer's 
thought  process.  Owns  the  following  sets: 

S. AMMO  (SUPPLY  AMMUNITION).  Contains  the  various 

ammunition  types  (SCL.V. ITEMS)  which  each  supply 
officer  must  stock. 
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S . UNIT  (SUPPLY  UNIT).  Contains  the  unit's  supply 
vehicles  (TANKS) . 

SWANT. LIST  (SUPPLY  BANT  LIST).  Contains  the  unit's 
outstanding  requisitions  (EES. BEQ)  that  must  be 
filled. 

SCONVOY (SUPPLY  CONYOY) .  Set  cf  ELEMENTS  which  Bake  up  a 
convoy.  ELEMENTS#  in  turn#  is  coaposed  of  a  set  of 
supply  vehicles (TANKS)  designated  for  a  supply 
Mission. 

ry_  E  ntiti.es 

CCL.V. ITEM (COMPANY  CLASS  ¥  ITEM).  Holds  information  for  a 
coapany  about  a  particular  aaao  type  owned  by  the  unit. 
Belongs  to  the  set  C.AMMO. 

CONVOY.  Holds  information  as  to  the  type  and  amount  of 

supplies  being  sent  to  a  particular  unit.  Owns  ELEMENTS 
which  make  up  a  convoy.  ELEMENTS#  in  turn#  owns  the 
trucks  (TANKS)  that  have  been  designated  to  carry  the 
supplies. 

PCL.V. ITEM  (PLATOON  CLASS  V  ITEM).  Holds  information  for  a 
platoon  about  a  particular  ammo  type  used  by  the  unit. 
Belongs  to  the  set  PLT.AMMO. 
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RES .  REQ (RESUPPLY . REQUISITION) .  Models  a  present  day 

requisition  form.  Provides  information  between  users 
and  the  supply  system.  A  RES. REQ  is  used  to  hold 
requirements  information  for  a  variety  of  purposes 
through  its  membership  in  various  sets.  These  are: 

C. WANT. LIST.  Company  information  owned  by  a 
COMPANY. COMMANDER. 

sw ANT. LIST.  Supply  information  owned  by  a 
SUPPLY. OFFICER. 

C . C60. LIST .  Convoy  cargo  list  owned  by  a  CONVOY. 

SCL. V. ITEM  (SUPPLY  CLASS  V  ITEM).  Holds  information  for  a 
supply  unit  about  a  particular  ammo  type  used  by  the 
unit.  Belongs  to  the  set  S.AMHO. 

T. CGO (TRUCK  CARGO).  Holds  information  concerning  the 

supplies  loaded  on  a  truck.  Belongs  to  the  set  CARGO. 
TANK (*) .  Represents  any  vehicle  or  weapon  system  on  the 

battlefield.  Used  to  distinguish  individual  vehicles  as 
to  type  and  function.  Tanks  belong  to  several 
distinguishing  sets: 

TNK.  ALIVE  (TANK  ALIVE)  (*) .  Owned  by  the  system  this  set 
keeps  track  of  the  alive/dead  status  of  individual 
TANKS. 
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PLAT. UNIT (PLATOON  UNIT).  Combat  systems  and  vehicles 
belong.  Owned  by  a  PLATOON. LEADER . 

S. UNIT (SUPPLY  UNIT).  Supply  vehicles  only  belong  to  this 
set  which  is  owned  by  a  SUPPLY. OFFICES. 

M.  ELEMENTS.  Specifies  membership  in  a  CONVOY. 

4 .  Attributes 

Permanent  Attributes  (INTEGER) 

N.CCL. V. ITEMS (NUMBER  OF  COMPANY  CLASS  V  ITEMS). 

COMPANY. COMMANDER  attribute  specifying  the  number  of 
ammunition  types (CCL. V . ITEMS)  used  by  the  company. 
N.PCL.V. ITEMS (NUMBER  OF  PLATOON  CLASS  V  ITEMS). 

PLATOON. LEADER  attribute  specifying  the  number  of 
ammunition  types (PCL.V. ITEMS)  used  by  the  platoon. 
N.SCL.V. ITEMS (NUMBER  OF  SUPPLY  CLASS  V  ITEMS). 

SUPPLY. OFFICER  attribute  specifying  the  number  of 
ammunition  types (SCL. V. ITEMS)  used  by  the  battalion 
supply  officer. 

PCO.CDR (PLATOON  COMPANY  COMMANDER).  Specifies  a  platoon's 
commander. 

REQN (REQUISITION) .  Attribute  of  a  COMPANY. COMMANDER 

specifying  the  total  number  of  resupply  reguests  filed 


by  a  commander. 


SCO. CDS  (SUPPLY  COMPANY  COMMANDS!!).  Specifies  a  supply  unites 


commander . 


S4 .  OFF  (S4  OFFICER)  .  Attribute  of  a  COMPANY.  COMMANDEfi 
specifying  the  unit's  supply  officer. 

Temporary  Attributes  (ALPHA) 

STATUS.  Attribute  of  a  RES.REQ  indicating  where  the  request 
currently  is.  Its  possible  values  are:  TOS4 ,  TOCO,  and 
TOATP. 

CNOMEN (COMPANY  NOMENCLATURE) .  Attribute  Of  a  CC1.V.ITEM 
containing  the  nomenclature  of  a  particular  ammo. 

PNOHEN  (PLATOON  NOMENCLATURE)  . 

3 NO MEN (RESUPPLY  NOMENCLATURE).  Attribute  of  a  RES.REQ 
specifying  the  requested  ammo's  nomenclature. 

SNOMEN  (SUPPPLY  NOMENCLATURE).  Attribute  of  a  SCL.V.ITEM 
specifying  the  requested  ammo's  nomenclature. 

TNOMEN  (T.CGO  NOMENCLATURE).  Attribute  of  T.CGO  containing 
the  name  of  the  ammunition  item  carried. 


AMMOI  (*)  (AMMUNITION  1).  This  variable  is  used  as  a  shortened 
form  for  AP.TOH  ammunition. 

AMH02 (*) (AMMUNITION  2).  This  variable  is  used  as  a  shortened 
fora  for  HE. DRAG  ammunition. 
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AHHQ3  {*)  (A HMD NITION  3).  This  variable  is  used  as  a  shortened 
form  for  Atf1.0H.MSI3  ammo. 

AMH04 (*) (AHHONITION  4).  This  variable  is  used  as  a  shortened 
form  for  Atf2.OB.ADH  ammo. 

AMM05 (*)  (AHHONITION  5).  Actual  on-hand  balance  of  the  fifth 
ammo  type  fired  by  a  TANK. 

AMM06 (*)  (AHHUNITION  6).  Actual  on-hand  balance  of  the  sixth 
ammo  type  fired  by  a  TA $ K. 

AP.TOtf (*) (ARHOH  PISBCING/TOtf)  Actual  on-hand  balance  of  the 
first  ammo  type  fired  by  a  TANK. 

TAC (TANK  AHHONITION  CODE).  Supply  code  which  points  to  a 
specific  ammunition  fired  by  a  TANK.  Six  are  specified 
on  a  TANK: 

TAC 1  (TANK  AHHONITION  CODE  1).  Contains  the  code  value 
for  the  first  ammo  type  fired  by  a  TANK. 

TAC2  (TANK  AHHONITION  CODE  2).  Contains  the  code  value 
for  the  second  ammo  type  fired  by  a  TANK. 

TAC3  (TANK  AHHONITION  CODE  3).  Contains  the  code  value 
for  the  third  ammo  fired  by  a  TANK. 

TAC4  (TANK  AHHONITION  CODE  4).  Contains  the  code  value 
for  the  fourth  ammo  fired  by  a  TANK. 
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TAC5 (TANK  AMMUNITION  CODE  5).  Contains  the  code  value 
for  the  fifth  anao  fired  by  a  TANK. 

TAC6  (TANK  AMMUNITION  CODE  6).  Contains  the  code  value 
for  the  sixth  amao  fired  by  a  TANK. 

AW1 .OR. MSL3(*) (ALTER  WEAPON1  OR  MISSILE3  AMMUNITION).  Actual 
on-hand  balance  for  the  third  amao  fired  by  a  TANK. 

AW2.  OR.  ADM  ("*)  (ALTER  WEAPON  2  OR  AIR  DEF  MISSILE).  Actual 
on-hand  balance  for  the  fourth  aaao  fired  by  a  TANK. 

C.CMBT. LOSS (COMPANY  COMBAT  LOSS).  Attribute  of  a  CCL.V.ITEM 
indicating  whether  the  need  for  an  aaao  type  is  still 
viable. 

C. MV. STATE  (CONVOY  MOVEMENT  STATE).  Indicates  if  a  convoy  has 
left  its  start  point.  Equals  "0"  at  the  start  point  and 
”1"  if  departed. 

C. NUM. REQ (COMPANY  NUMBER  OF  REQUESTS).  Attribute  of  a 

CCL.V.ITEM  containing  the  total  nuaber  of  requests  Bade 
for  that  aaao  type. 

C.RND.CNTR  (COMPANY  ROUND  COUNTER) . Arguaent  for  the  event 

UP . COM. AMMO ,  points  to  the  weapon  systea  it  is  updating. 

C. SHORT  (COMPANY  SHORTAGE).  Attribute  of  a  CCL.V.ITEM  holding 
the  nuaber  of  rounds  the  coapany  is  short  for  that  round 
type. 
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CAC (COMPANY  AMMUNITION  CODE).  Attribute  of  a  CCL.V.ITEH 
which  points  to  a  specific  anno  type  fired  by  the 
company  weapon  systems. 

CAMHO. LON (COMPANY  AMMUNITION  LEVEL  OP  NEED).  Attribute  of  a 
CCL.V. ITEM  indexing  the  company’s  overall  need  for  an 
ammo  type. 

CC'JRR.  LOAD  (COMPANY  CURRENT  LOAD).  Attribute  of  a  CCL.V.ITEH 
holding  the  company  commander's  knowledge  of  the  on-hand 
balance  for  rounds  of  a  particular  type. 

CO. B. LOAD (COMPANY  BASE  LOAD).  Attribute  Of  a  CCL.V.ITEH 

holding  the  total  number  of  rounds  the  company  needs  to 
be  at  optimal  fill. 

CO. CNVY (COMPANY  convoy).  Argument  of  event  co. resupply. arr 
(COMPANY  RESUPPLY  ARRIVE)  pointing  to  the  CONVOY 
arriving, 

COCDR (COMPANY  COMMANDER).  Attribute  of  a  TANK  pointing  to 
its  COMPANY. COMMANDER. 

COLOR (*) .  Attribute  of  TANK  indicating  the  TANK'S  force 
membership. 

"0"  indicates  RED  FORCE 
"I"  indicates  BLUE  PORCE 

CONTRKS (CONVOY  TRUCKS).  Attribute  of  a  CONVOY  specifying  the 
number  of  vehicles  in  a  particular  convoy. 
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CPNTR  (CONVOY  POINTER).  Attribute  of  a  T.C30  pointing  to  the 
convoy  the  cargo  is  leaded  on. 

CRESOPPLY.SEQ (COMPANY  RESUPPLY  REQUEST).  Attribute  of  a 
CCL.V. ITEM  indicating  whether  a  RES.REQ  has  been 
subaitted  previously. 

CU.  PK3  (CUBE  PACKAGE).  Attribute  of  a  SCL .  V.  ITEM  specifying 
the  cube  of  an  annunition  pallet. 

DEMAND.  Attribute  of  a  SCL. V. ITEM  holding  the  total  denand 
for  an  anno  type. 

DISTR (DISTRIBUTOR) .  Arguaent  for  event  REDISTRIBUTE  pointing 
to  the  unit's  PLATOON. LEADER 

FKILL  (FIREPOWER  KILL)  (*) .  Indicates  whether  a  TANK  has 

sustained  a  firepower  kill  during  the  battle. 

"0"  indicates  no 
"I"  indicates  yes 

MARCH. ORDER.  Arguaent  for  the  event  MOVE  holding  the  pointer 
of  the  coapany  receiving  orders  to  aove. 

HE. DRAG (HIGH  SXPLOSIVE/DRAGON  AMMUNITION)  (*)  .  Actual  on-hand 
balance  of  the  second  anno  type  fired  by  a  TANK. 

ISSUER.  Arguaent  of  event  UP. S4. AMMO  pointing  to  the  S-4 
currently  updating. 

ISSUES.  Arguaent  of  event  UP. S4. AMMO  pointing  to  the  coapany 
initiating  the  reguest  for  resupply. 
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KKILL  (CATASTROPHIC  KILL)  (*)  .  Indicates  whether  a  TANK  has 

sustained  a  catastrophic  kill  during  the  battle. 

"0W  indicates  no 
"1M  indicates  yes 

MANIFEST.  Attribute  of  a  RES.REQ  pointing  to  the  CONVOY 
supplies  are  loaded  on. 

MAX. CUBE.  Attribute  of  a  TANK  indicating  its  nax  cargo  cube. 

MAX. NT.  Attribute  of  a  TANK  indicating  its  lax  cargo  weight. 

MFKILL  (MOBILITX/FIREPOHER  KILL)  (*) .  Indicates  whether  a  TANK 

has  sustained  aobility  and  firepower  daaage. 

"O’*  indicates  no 
"I"  indicates  yes 

MKILL (MOBILITY  KILL) (*) .  Indicates  whether  a  TANK  has 

sustained  aobility  daaage. 

"0"  indicates  no 
"1W  indicates  yes 

N.T. ALLOC (NUMBER  OF  THUCKS  ALLOCATED)  .  Attribute  of  a 

RES.REQ  indicating  the  total  nuaber  of  trucks  allocated 
to  aove  a  RES.REQ. 

NAME (*)  .  Indicates  the  nuaber  of  a  TANK  in  the  battle. 

ONHAND.  Attribute  of  a  SCL.7.ITEE  holding  the  balance 
on-hand  of  stocks  for  an  aaao  type. 

OH 1 (ON-HAND  1).  Current  balance  of  aaaunition  1  on  a  TANK. 

OH2 (ON-HAND  2).  Current  balance  of  aaaunition  2  on  a  TANK. 

OH3 (ON-HAND  3).  Current  balance  of  aaaunition  3  on  a  TANK. 
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0H4 (ON-HAND  4).  Current  balance  of  aaaunition  4  on  a  TANK. 

OHS (ON-HAND  5).  Current  balance  of  aaaunition  5  on  a  TANK. 

0H6 (ON-HAND  6).  Current  balance  of  aaaunition  6  on  a  TANK. 

P .CHBT .LOSS (PLATOON  COHBAT  LOSS).  Attribute  of  a  PCL.V.ITEH 
indicating  whether  the  need  for  an  aaao  type  is  still 
viable. 

P.RND.CNTR (PLATOON  ROUND  COUNTER).  Arguaent  of  event 

UP.PLT.AHHO  pointing  to  the  platoon  currently  updating. 

P. SHORT  (PLATOON  SHORTAGE).  Attribute  of  a  PCL.V.ITEH  holding 
the  quantity  of  that  aaao  the  platoon  is  currently 
short. 

PAC (PLATOON  AHHUNITION  CODE).  Attribute  Of  a  PCL.V.ITEH 
which  points  to  a  specific  aaao  type  fired  by  the 
platoon. 

PAHMO. LON (PLATOON  AHHUNITION  LEVEL  OP  NEED).  Attribute  of  a 
PCL.V.ITEH  indexing  the  platoon's  overall  need  for  an 
aaao  type. 

PCURR. LOAD (PLATOON  CURRENT  LOAD).  Attribute  of  a  PCL.V.ITEH 
holding  the  platocn  leader's  knowledge  of  the  on- hand 
balance  for  rounds  of  a  particular  type. 

PNOHEN  (PLATOON  NOHENCL ATURE)  .  Attribute  of  a  PCL.V.ITEH 
containing  the  noaeaclature  of  a  particular  aaao. 
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PL.  8 . LOAD (PLATOON  BASE  LOAD).  Attribute  Of  a  PCL.V.ITEM 

holding  the  total  number  of  rounds  the  platoon  needs  to 
be  at  optimal  fill  for  that  type  ammunition. 

PLTLDB (PLATOON  LEADER)  (*) .  Attribute  of  a  TANK. 

POINTER  (rt) .  Contains  the  machine  address  of  a  particular 
TANK. 

RAC (RESUPPLY  AMMUNITION  CODE).  Attribute  of  an  SCL. V . ITEM 
which  points  to  a  specific  ammo  type  carried  by  the 
supply  unit. 

RCNVY (RESUPPLY  CONVOY).  Argument  of  event  BN. ARRIVE  pointing 
to  a  specific  convoy. 

RDS.PKG  (ROUNDS  PACKAGE).  Attribute  Of  a  SCL. V. ITEM 

specifying  the  number  cf  rounds  on  an  ammo  pallet. 

REQUESTOR.  Attribute  of  a  RES. REQ  pointing  to  the  requesting 
unit. 

RFILL (RESUPPLY  FILL).  Attribute  of  a  RES. REQ  specifying  the 
amount  of  ammunition  released  to  fill  a  request. 

RND.CNTR (ROUND  COUNTER).  Argument  of  event  UP. N. AMMO 
pointing  to  the  TANK  currently  updating. 

RP (RELEASE  POINT).  Attribute  of  a  CONVOY  specifying  its 
destination. 
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RPNTR (REQUEST  POINTER).  Attribute  of  a  RES.REQ  containing 
its  pointer  value. 

RRPNTR (RES.REQ  POINTER).  Attribute  of  T.CGO  which  points  to 
the  RES.REQ  the  supplies  are  leant  to  fill. 

RQTY (RESUPPLY  QUANTITY) .  Attribute  of  a  RES. REQ  holding  the 
total  quantity  requested  by  a  unit. 

RAC (RESUPPLY  AMMUNITION  CODE).  Attribute  of  a  RES.REQ  which 
points  to  a  specific  aaao  being  requested. 

SAC (SUPPLY  AMMUNITION  CODE).  Attribute  of  a  SCL.V.ITEM 

pointing  to  the  particular  aaao  carried  by  the  supply 
unit. 

SCREEN.  Attribute  of  a  RES.REQ  indicating  whether  a  RES. REQ 
has  been  looked  at  during  an  S-4  update. 

SL0AD1  (STONED  LOAD  1).  Attribute  of  a  TANK  specfying  the 
optiaal  load  for  aaao  type  1. 

SL0AD2  (STONED  LOAD  2).  Attribute  of  a  TANK  specfying  the 
optiaal  load  for  aaao  type  2. 

SLOAD3  (STONED  LOAD  3).  Attribute  of  a  TANK  specfying  the 
optiaal  load  for  aaao  type  3. 

SLOAD4 (STONED  LOAD  4).  Attribute  of  a  TANK  specfying  the 
optiaal  load  for  aaao  type  4. 
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SL0AD5 (STO WBD  LOAD  5).  Attribute  of  a  TANK  specfying  the 
optiaal  load  for  aaao  type  5. 

SLOAD6 (STOWED  LOAD  6) .  Attribute  of  a  TANK  specfying  the 
optiaal  load  for  aaao  type  6. 

SP (START  POINT).  Attribute  of  a  CONVOY  specifying  its 
origin. 

SPACE.  Attribute  of  a  CONVOY  holding  the  aaount  of  loading 
space  available  on  trucks  in  the  convoy. 

SPRIORITY  (SUPPLY  PRIORITY).  Attribute  Of  a  RES.REQ 


specifying  the  urgency  of  need  for  the  aaao  request. 
SUPOFF (SUPPLY  OFFICER) (*) .  Attribute  of  a  resupply  vehicle. 
SYS. TYPE  (SYSTEH  TYPE)  (*)  .  Attribute  of  a  TANK  specifying  the 
general  sysfea  type  of  the  entity. 


1  TANK 

2  Hpunted  infantry 

3  Discounted  Infantry 

a  Artillery 

6  Air  Defense 

7  Supply 

8  ComS/EW/Acq/Intel 

9  Other 

TCU (TRUCK  CUBE).  Attribute  of  a  TANK  holding  the  aaxiaua 
cube  loaded  on  a  truck. 

TPNTR (TRUCK  POINTER).  Attribute  of  a  T.CGO  pointing  to  the 
truck  it  is  loaded  on. 

TQTY (T.CGO  QUANTITY).  Attribute  of  a  T.CGO  containing  the 
quantity  loaded  as  cargo. 
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RAC  (T .  CGO  RESUPPLY  AMMO  CODE).  Attribute  of  T.CGO  pointing 


.  to  the  aaao  type  loaded  as  cargo. 

TWT (TR OCR  WEIGHT).  Attribute  of  a  TANK  holding  the  aarimua 
weight  it  can  carry. 

TIME.  Attribute  of  a  RES.REQ  containing  the  tiae  a  reguest 
is  initiated  at  the  coapany. 

wloh 1 (WEAPON  LEVEL  OF  NEED  1).  Weapon  systea  urgency  of  need 
AMM0 1. 

WL0N2  (WEAPON  LEVEL  OF  NEED  2).  Weapon  systea  urgency  of  need 
ANH02. 

WLON3 (WEAPON  LEVEL  OF  NEED  3).  Weapon  systea  urgency  of  need 
ANM03. 

WL0N4 (WEAPON  LEVEL  OF  NEED  4).  Weapon  systea  urgency  of  need 
AMM04. 

WLON5 (WEAPON  LEVEL  OF  NEED  5).  Weapon  systea  urgency  of  need 
AMM05. 

WL0N6 (WEAPON  LEVEL  OF  NEED  6).  Weapon  systea  urgency  of  need 
AMM06. 

WPN.TTPE  (WEAPON  TYPE)  (*) .  Attribute  of  a  TANK  specifying  the 
specific  weapon  systea  within  a  SIS. TIPE  (SYSTEM  TYPE). 

WT.PKG (WEIGHT  PACKAGE).  Attribute  of  a  SCL.Y.ITEM  specifying 
the  weight  of  a  pallet  of  the  aaao  being  considered. 

( 


. i 


131 


5.  §ets 

The  sets  used  in  the  model  are  listed  ar.d  defined  as 

follows: 

C.CGO. LIST  (CONVOY  CARGO  LIST).  Owned  by  a  CONVOY .  Members 
are  RES.REQs. 

CO. AMMO (COMPANY  AMMUNITION) .  Owned  by  a  COMPANY. COMMANDER. 

Members  are  the  unit's  CCL.V. ITEMS. 

CO. UNIT  (COMPANY  UNIT).  Owned  by  a  COMPANY. COMMANDER.  Members 
are  unit  PLATOON. LEADERS. 

CARGO (TRUCK  CARGO).  Owned  by  a  supply  vehicle.  Members  are 
the  supplies  (T.CGO)  loaded. 

CHANT. LIST  (COMPANY  WANT  LIST).  Owned  by  a  COMPANY. COMMANDER. 

Attributes  are  the  unit's  outstanding  resupply  requests. 
ELEMENTS.  Owned  by  a  convoy.  Members  are  TANKS  in  the 
convoy, 

PLAT. UNIT (PLATOON  UNIT).  Owned  by  a  PLAYOON. LEADER.  Members 
are  unit  combat  vehicles. 

PLT. AMMO  (PLATOON  AMMUNITION).  Owned  by  a  PLATOON . LEADER. 

Members  are  the  platoon  PCL.V. ITEMS. 

S. AMMO  (SUPPLY  AMMUNITION).  Owned  by  a  SUPPLY .OFFICER. 

Members  are  the  supply  unit's  SCL. 7. ITEMS. 
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S. UNIT  (SUPPLY  UNIT).  Owned  by  a  SUPPLY .OFPICEB.  Members  are 


unit  supply  trucks. 

SCONVOY (SUPPLY  CONVOY).  Owned  by  a  SUPPLY. OFPICEB.  Meabers 
are  convoys  dispatched  by  the  supply  unit. 

SHEQN. LIST (SUPPLY  REQUISITION  LIST).  Owned  by  a 

SUPPLY .OFPICEB.  Members  are  the  supply  unit's 
outstanding  RES.REQs  sent  to  the  ATP . 

SUP. OFF (SUPPLY  OFFICER).  Attribute  of  TANK  pointing  to  its 
supply  officer. 

SWANT. LIST (SUPPLY  WANT  LIST).  Owned  by  a  SUPPLY. OFFICER. 

Members  are  RES.REQs  froa  the  coabat  units. 

TNK.  ALIVE  (TANK  ALIVE)  (*)  .  Owned  by  the  system.  Meabers  are 
vehicles  still  alive  within  the  simulation. 

6.  global ■Variables 

The  global  variables  used  in  the  aodel  are  either 
alpha,  integer  or  real.  An  explanation  of  their  use  is  as 
follows: 

Giobal_V5£iablSS.ili£flAI 

NOMEN (NOMENCLATURE) .  Specifies  the  names  of  the  rounds 
played. 


* 

I 
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CCODS (COMPANY  CODE).  Holds  the  pointer  value  for  a  company's 
CCL. V. ITEMS 

CNUM (COMPANY  NO MBEH)  (*) .  Specifies  the  number  of 
COMP ANY. COMMANDERS  created. 

CSTREAM  (COMPANY  STREAM).  Specifies  the  random  number  stream 
used  for  company  calculations. 

N. SYS  (NUMBER  OP  SYSTEMS).  Specifies  the  number  of  weapon 
systems  created  for  the  simulation. 

N.  TANKS  (NOMBER  OF  TANKS).  Specifies  the  number  of  vehicles 
created  for  the  simulation. 

N. WPN. TYPES (NUMBER  OF  WEAPON  TYPES).  Specifies  the  number  of 
weapons  created  for  the  simulation. 

PCODE (PLATOON  CODE)  (2-d).  Holds  the  pointer  value  for  a 
platoon's  PCL.V. ITEMS. 

PNUM  (PLATOON  NUMBER)  (*) .  Specifies  the  number  of 
PLATOON. LEADERS  created  for  a  simulation. 

PSTREAM  (PLATOON  STREAM).  Specifies  the  random  number  stream 
to  be  used  for  platoon  calculations. 

RCODE (REQUEST  CODE)  (2-d).  Holds  the  pointer  value  for 
resupply  requests  created. 

RSTREAM (RESUPPLY  STREAM).  Specifies  the  random  number  stream 
to  be  used  for  resupply  calculations. 


5C0DE (SUPPLY  CODE) (2-d)  .  Holds  the  pointer  value  for  a 
supply  unit's  SCL.V. ITEMS. 

SNUM (SUPPLY  NUMBER).  Specifies  the  number  of  SUPPLY. OFFICERS 
created  for  a  simulation. 

TSTREAM (TR IP  STREAM) .  Specifies  the  random  number  stream  to 
be  used  for  movement  calculations. 

WSTB2AM (WEAPON  STREAM).  Specifies  the  random  number  stream 
to  be  used  for  weapon  update  calculations. 

Global  Variables  (REAL) 

3.  END  (BATTLE  END).  Holds  the  termination  time  for  a  day's 
battle . 

B.  START (BATTLE  START)  .  Holds  the  beginning  time  for  a  day's 

battl«. 

C. L1PCT (CRITICAL  LON1  PERCENTAGE).  Holds  the  maximum 

percentage  that  LON1  requisitions  may  be  reduced  to  in 
order  to  release  space  on  a  convoy  for  other  critical 
LON  1  and  LON 2  requests. 

C.L2CU  (CRITICAL  L0N2  CUBE).  Holds  the  maximum  percent  of 
cube  that  L0N2  requisitions  may  be  cut  to  in  order  to 
release  space  on  a  convoy  for  other  critical  LON1  and 
LON2  requisitions. 
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C.L2H T (CRITICAL  L0N2  HEIGHT).  Holds  the  maximum  percent  of 
weight  that  L0N2  requisitions  may  be  cut  to  in  order  to 
release  space  on  a  convoy  for  other  critical  L0N1  and 
L0N2  requisitions. 

CMAX(COMPANY  MAXIMOM) .  The  maximum  time  that  can  elapse 
before  a  company  will  update  its  ammunition  status. 

CHIN (COMPANY  MINIMUM) .  The  minimum  time  that  can  elapse 
before  a  company  will  update  its  ammunition  status. 

COMLON  (COMPANY  LEVEL  OF  NEED)  (2-d) .  Array  holding  the  value 
of  a  COMPANY. COMMANDERS  cutoff  percentages  for  the  five 
levels  of  need  which  can  be  assigned.  Dimensioned  as 
MAX. CL. V. ITEMS (MAX  CLASS  V  ITEMS)  by  5. 

MAXTRIP (MAX  TRIP).  The  maximum  time  required  for  a  convoy  to 
reach  its  intended  destination. 

M INTRIP  (MIN  TRIP).  The  minimum  time  required  for  a  convoy  to 
reach  its  intended  destination. 

PLTLON (PLATOON  LEVEL  OF  NEED)  (2-d) .  Array  holding  the  value 
of  a  PLATOON. LEADERS ' s  cutoff  percentages  for  the  five 
levels  of  need  which  can  be  assigned.  Dimensioned  as 
MAX. CL. V. ITEMS (MAX  CLASS  V  ITEMS)  by  5. 

PMAX (PLATOON  MAXIMUM).  The  maximum  time  that  can  pass  before 
a  platoon  will  update  its  ammunition  status. 
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PMIN (PLATOON  MINIMUM).  The  minimum  time  that  can  pass  before 
a  platoon  will  update  its  ammunition  status. 

POD (PROBABILITY  OF  DAMAGE)  (2-d) .  Array  holding  the 

probability  of  damage  for  the  various  weapon  types  and 
types  of  damage.  Dimensioned  N . WPN. TYPES  (NUMBER  OF 
WEAPON  TYPES)  by  4. 

POF  (PROBABILITY  OF  FIRE)  (2-d).  Array  holding  the  probability 
of  firing  for  the  various  weapon  types  and  ammunitions 
fired.  Dimensioned  N. WPN. TYPES (NUMBER  OF  WEAPON  TYPES) 
by  4 . 

ROF  (RATE  OF  FIRE)  (2-d).  Specifies  the  rates  of  fire  for  the 
six  weapons  of  any  weapon  system.  Dimensioned 
N. WPN. TYPES (NUMBER  OF  WEAPON  TYPES)  by  6. 

WMAX (WEAPON  MAXIMUM).  The  maximum  time  that  can  pass  before 
a  weapon  will  update  its  ammunition  status. 

WMIN (WEAPON  MINIMUM).  The  minimum  time  that  can  pass  before 
a  weapon  will  update  its  ammunition  status. 

WPNLON (WEAPON  LEVEL  OF  NEED)  (2-d).  Array  holding  the  value 
of  a  weapon  system's  cutoff  percentages  for  the  five 
levels  of  need  which  can  be  assigned.  Dimensioned  as 
MAX. CL. V. ITEMS (MAX  CLASS  V  ITEMS)  by  5. 
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7 .  Listing 


1  PREAMBLE 

DEFINE  WPNLON ,PLTLON. A ND  COMLON  AS  REAL, 2-DIM  ARRAYS 
DEFINE  ROF  AS  INTEGER, 2-DIM  ARRAY 
DEFINE  NOMEN  AS  AN  ALPHA, 1-DIM  ARRAY 
DEFINE  PLACES  AS  A  2-DIM  INTEGER  ARRAY 

•  • 

DEFINE  POD  AS  REAL, 2-DIM  ARRAY 
GENERATE  LIST  ROUTINES 

1 1 

THE  SYSTEM  OiNS  SOME  TNK. ALIVE 

i  $ 

•  • 

PERMANENT  ENTITIES 

•  i 

EVERY  COMPANY. COMMANDER  HAS  AN  N .CCL . V. ITEMS , 

AN  S4 . OFF, A  REQN , 

OWNS  A  CO. UNIT, A  CHANT . LIST , AND  SOME  CO. AMMO 
DEFINE  N. CCL. V. ITEMS, S4. OFF, REQN  AS  INTEGER 
VARIABLES 

•  • 

EVERY  PLATOON. LEADER  HAS  A  ?CO.CDR,AN  N. PCL. V. ITEMS, 
HAY  BELONG  TO  A  CO. UNIT, 

AND  MAY  OHN  A  PL AT . UNIT, AND  A  PLT.AMMO 

DEFINE  PCO.CDR,  N . PCL. V. ITEMS  AS  INTEGER  VARIABLES 

•  • 

EVERY  SUPPLY. OFFICER  HAS  A  SCO.CDR.A  N. SCL. V. ITEMS, 
OWNS  SOME  S.AMMO,  AN  S. UNIT. AN  SWANT . LIST , 

AN  SREQN.LIST,  AND  AN  SCONVOY 

DEFINE  SCO. CD R,  N . SCL. V . ITEMS  AS  INTEGER  VARIABLES 
•  • 

« t 

TEMPORARY  ENTITIES 

«  « 

EVERY  TANK  HAS  A  NAME, A  COLOR, A  SYS. TYPE, A  IPN.TYPE, 
A  POINTER, AN  AP.TOH.AN  HE. DRAG, AN  AH  1. OR. MSL3, 

AN  AH2.0R. ADM. AN  AHM05 , AM  AMMOo , 

A  SLOAD  1 , A  SLOAD2, A  SLOAD3 , A  SL0AD4.A  SLOAD5 . 

A  SLOAD6 . AN  OH1,AN  OH2.AN  0H3.AN  OH4.AN  OH5.AN  OH6, 

A  HLON1 , i  WLON2, A  HLON3,A  HLON4 , A  HLQN5, A  HLON6, 

AN  TAC1.AN  TAC2.AN  TAC3 ,  AN  TAC4 ,  AN  TAC5.  AN  TAC6 , 

A  PLTLDR , A  COCDR,A  SUPOFF.A  MAX. HT,A  MAX. CUBE, 

A  THT.A  TCU 

AN  MKlLL,AN  FKILL,AN  MFKILL,A  KKILL, 

AND  MAY  BELONG  TO  A  TNK. ALIVE, A  PLAT. UNIT, A  S.UNIT, 
AND  A  ELEMENTS, AND  HAY  OHN  SOME  CARGO 

• « 

DEFINE  N. TANKS  AS  AN  INTEGER  VARIABLE 
DEFINE  NAME.COLOR. SYS. TYPE, HPN. TYPE, SUP. OFF, POINTER, 
A? . TOW, HE. DRAG , AH i .OR. MSL3 , AH2. OR. ADM, AMM05, AMMQ6 , 
SLOAD 1 . SLOAD2 , SLOAD3 ,SL0AD4, SLOAD5, SLOAD 6, 
0H1,0H2.0H3,0H4,0H5,0H6, 

HLON1 , H  LON2, W  L0N3 , HLON  4 , HLON5, HL0N6, 
TAC1.TAC2.TAC3,TAC4,TAC5.TAC6. 

PLTLDR, COCDR, SOPOFF, MAX. HI ,MA2 .COBB, 

TWT.TCU 

MR ILL, FKILL, MFKILL, AND  KKILL  AS  INTEGER  VARIABLES 

EVERY  T.CGO  HAS  A  TPNTR.A  RRPNTR,  A  ILiJ,  A  TNOMEN, 

A  TQTY , AND  MAY  BELONG  TO  A  CARGO 

DEFINE  TPNTR, RRPNTR, TRAC. TQTY  AS  INTEGER  VARIABLES 
DEFINE  TNOMEN  AS  AN  ALPHA  VARIABLE 

EVERY  CONVOY  HAS  AN  SP.AN  RP.A  CONTRKS, A  SPACE. 

A  C. MV. STATE, A  CPNTR ,M AY  BELONG  TO  A  SCONVOY, MAY  OHN 


13S 


65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 
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89 
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96 
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SOME  ELEMENTS,  AND  A  C.CGO.LIST 

DEFINE  CPNTR, SP.RP, SPACE, C.MV. STATE, AND  CONTRKS  AS 
INTEGER  VARIABLES 

« i 

EVEHY  PCL. V . ITEM  HAS  A  PAC,A  PNOMEN.A  PL. B. LOAD, 

A  PCORR. LOAD. A  PAMHO . LON , A  P . CMBT. LO SS , A  P. SHORT, AND 

MAY  BELONG  TO  A  PLT. AMMO 

DEFINE  P AC, PL . B. LOAD .PCORR , LOAD, 

PAMMO. LON, P. SHORT, P.CMBT. LOSS  AS  INTEGER  VARIABLES 
DEFINE  PNOMEN  AS  AN  ALPHA  VARIABLE 
• « 

EVERY  CCL. V .ITEM  HAS  A  CAC.A  CNOMEN ,A  CO. B. LOAD, 

A  CCORR. LOAD, A  C.NUM.REQN.A  CAMMO.LuN. A  C. SHORT, 

A  C. CHBT. LOSS, AND  MAY  BELONG  TO  A  CO. AMMO 

DEFINE  CAC,CO . B. LOAD, CCURa . LOAD, C. NUM.REQN,C . SHORT, 

C . CMBT. LOSS ,C AMMO .LON  AS  INTEGER  VARIABLES 

DEFINE  CNOMEN  AS  AN  ALPHA  VARIABLE 
•  • 

EVERY  SCL. V . ITEM  HAS  AN  SAC, AN  S NOHEN, A  NT.PKG, 

A  CU.PKG.A  RDS . PKG , A  DEMAND, AN  ONHAND, AND 
BELONGS  TO  AN  S.AMHO 
DEFINE  SAC, RDS. PKG, DEMAND, ONHAND  AS 
INTEGER  VARIABLES 

DEFINE  SNONEN  AS  AN  ALPHA  VARIABLE 
DEFINE  NT. PKG, AND  CO. PKG  AS  REAL  VARIABLES 

i  • 

EVERY  RES.REQ  HAS  A  REQUESTOR. A  RQTY.A  RAC, 

AN  R NOHEN. AN  SPRIORITY.A  STATUS. A  TIME. AN  RFILL. 

AN  N.T.ALlOC.A  MANIFEST. A  SCREEN.AN  RPNTR,AND  HAY 
BELONG  TO  A  C.CGO.LIST, A  CHANT. LIST, 

AN  SREQN. LIST, AND  AN  SHANT.LIST 

DEFINE  REQUESTOR . RQTY, RAC. 5 PRIORITY, MANIFEST . 

RPNTR, SCREEN. BFltL.N.T. ALLOC  AS  INTEGER  VARIABLES 
DEFINE  TIME  AS  A  REAL  VARIABLE 
DEFINE  STATUS  AS  AN  ALPHA  VARIABLE 
DEFINE  HNOMEN  AS  A  ALPHA  VARIABLE 
« • 


GENERAL  DEFINITIONS 


« « 
i  • 

« « 

DEFINE  PNUH.CNUH , SNUH, NSTREAM.PS TREAM,CSTR£AM, 
TSTREAM, RSTRE AM, N. SYS, AND  N.NPN. TYPES 
AS  INTEGER  VARIABLES 

DEFINE  NMIN, NMAX, PHI N,PMAZ. CHIN, CMAI, 

HINTRIP , AND  MAXTRI?  AS  REAL  VARIABLES 
DEFINE  B. START, AND  B . END  AS  REAL  VARIABLES 
DEFINE  SNANT. LIST  AS  A  SET  RANKED  BY  LON  SPRIORITX, 
THEN  BY  LON  TIHE 

DEFINE  PCODB  AS  AN  INTEGER, 2-DIH  ARBAY 
DEFINE  CCODE  AS  AN  INTEGER , 2-DIM  ARRAY 
DEFINE  SCODE  AS  AN  INTEGER, 2-DIM  ARRAY 
DEFINE  RCODE  AS  AN  INTEGER, 2-DIH  ARRAY 
DEFINE  AMH01  TO  MEAN  AP.IOM 
DEFINE  AMH02  TO  MEAN  HE. DRAG 
DEFINE  AMM03  TO  MEAN  AN1.Ofi.HSL3 
DEFINE  AMM04  TO  MEAN  AH2.0E. ADM 
DEFINE  C.L2NT, C. L2C0 ,C . L2PCT,C. L 1PCT 
AS  REAL  VARIABLES 
•  • 

•  i 

•  i 

•  t 


EVENT  NOTICES 


EVENT  NOTICES  INCLUDE  STOP. SIHOLATION,B.  UP. DATE, 
AND  BAT.  L.  TIHE 

EVERY  UP. N. AMMO  HAS  A  RND.CNTR 

EVERY  UP.PLT.AHHO  HAS  A  P. RND.CNTR 

EVERY  UP.COM. AHHO  HAS  A  C. RND.CNTR 

EVERY  UP. S4. AMMO  HAS  A  ISSUER,  AND  AN  ISSUES 
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134  EVERT  MOVE  HAS  A  MARCH. ORDER 

135  EVERY  CO. RESUPPLY. ARR  HAS  A  CO.CNVY 

136  EVERY  BN. ARRIVE  HAS  AN  RCNVY 

137  EVERY  REDISTRIBUTE  HAS  A  DISTR 

138  EVERY  FIREKILL  HAS  A  VICTIM 

139  DEFINE  VICTIM ,RND . CNTR.P .END. CNTR. C. R ND.  CNTR , ISSUER, 

140  ISSUEE, CO. CNVI, MARCH. ORDER , RCNVY , AND  DISTR 

141  AS  INTEGER  VARIABLES 


B.  "MAIN" 


The  purpose  of  the  main  program  is  to  call  routines  that 
create  blue  forces,  to  schedule  the  events  that  generate 
data,  and  to  start/stop  the  simulation. 

EVENT  NOTICES 

B.  UP.  DATE  (BATTLE  UPDATE),  BAT.  L  .TIME  (BATTLE  TIME), 

STOP. SIMULATION 

RECURSIVE  VARIABLES  (REAL) 

SIM. STOP  Holds  the  time  for  simulation  termination. 

ROUTINES  CALLED 
BLU. CREATE 


£B0G£Afl_L£2TI£G 

1  MAIN 

2  •• 

3  DEFINE  SIM. STOP  AS  A  REAL  VARIABLE 

4  READ  SIM.  STOP 

5  SCHEDULE  A  STOP. SIMULATION  IN  SIM. STOP  DAIS 

6  SKIP  2  CARDS 

7  CALL  BLU. CREATE 

8  SCHEDULE  A  BAT. L. TIME  NON 

9  SCHEDULE  A  B. UP. DATE  NON 

10  PRINT  1  LINE  THUS 

START  SIMULATION 

11  START  SIMULATION 

12  STOP 

13  END 

EXPLANATION  OF  CODE 


Line  3  Defines  recursive  variables  used  in  the  routine. 
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Line  4  Heads  siaulation  stop  tiae. 

Line  5  Schedules  the  event  STOP .SIMULATION. 

Lina  7  Calls  routine  BLU. CREATE. 

Line  8  Schedules  the  first  BAT.L.TIME  event. 

Line  9  Schedules  printing  of  the  first  battle  suasary. 

Line  10  prints  a  stateaent  to  mark  siaulation  start. 

Line  11  System  coaaand  to  start  the  simulation. 

C.  "ROUTINE  BLU. CREATE" 

Routine  BLU. CREATE  is  called  froa  the  aain  prograa  to 
create  the  entities  of  each  blue  unit.  After  creating  these 
entities,  it  establishes  their  attributes  and  files  each 
entity  in  its  appropriate  set. 

EVENTS  SCHEDULED 
UP.  R. AN RO (UPDATE  HEAPON  AMMO). 


CNUM (COMPANY  NUMBER).  Specifies  the  nuaber  of 
CO HP AN 7. CON HAN DEBS  created. 

CSTREAM (COMPANY  RANDOM  NUMBER  STREAM) . 

N. COMPANY. COMMANDERS (NUMBER  OF  COMPANY  COMMANDERS) 
N. PLATOON. LEADERS  (NUMBEH  OF  PLATOON  LEADERS). 

N. SUPPLY. OFFICERS (NUMBER  OF  SUPPLY  OFFICERS). 

N. TANKS  (NUMBS7'  OF  TANKS). 

PNUM (NUMBEH  OF  PLATOONS). 
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4 

4 


■  ■  ***mm*. 


PSTREAM (PLATOON  RANDOM  NUMBER  STREAM). 

SNUM (NUMBER  OF  SUPPLY  OFFICERS). 

GLOBAL  VARIABLES  (REAL) 

CMAX (COMPANY  MAXIMUM).  The  aaxiaun  rime  that  can  pass  before 
a  company  will  update  its  aaaunition  status. 

CMIN (COMPANY  MINIMUM).  The  minimum  time  that  can  pass  before 
a  company  will  update  its  aaaunition  status. 

PMAX (PLATOON  MAXIMUM)  <  The  maximum  time  that  can  pass  before 
a  platoon  will  update  its  aaaunition  status. 

PMIN (PLATOON  MINIMUM) .  The  ainiaua  time  that  can  pass  before 
a  platoon  will  update  its  aaaunition  status. 

WHAX  (WEAPON  MAXIMUM).  The  aaxiaua  time  that  can  pass  before 
a  weapon  will  update  its  aaaunition  status. 

WHIN (WEAPON  MINIMUM).  The  ainiaua  tine  that  can  pass  before 
a  weapon  will  update  its  aaaunition  status. 

PERMANENT  ENTITIES 

COMPANY. COMMANDER,  PL ATOON . LEADER,  SUPPLY. OFFICER 

N.CCL. V. ITEMS.  Number  of  conpany  class  7  iteas  (unique  to  a 
coapany  coaaander) . 

N.PCL. 7 . ITEMS .  Number  of  platoon  class  7  items  (UNIQUE  TO  A 
PLATOON  LEADER) . 


142 


N. SCL. V. ITEMS .  Number  of  supply  class  7  items  (UNIQUE  TO  A 
SUPPLY  OPFICER) . 

PCO.CDR.  (PLATOON  COMPANY  COMMANDER). 

SCO. CDR.  (SUPPLY  COMPANY  COMMANDER). 

S4.0FP.  (COMPANY  S-4  OFFICER)  . 

RECURSIVE  VARIABLES  (INTEGER) 

I  -  Loop  index. 

ROUTINES  CALLED 

BASIC. LOAD,  PARAMETERS 

S£1S 

CO. UNIT  (COMPANY  UNIT).  Owned  by  a  COMPANY. COMMANDER. 

Members  are  the  unit's  PLATOON. LEADERS. 

PLAT. UNIT (PLATOON  UNIT).  Owned  by  a  PLATOON. LEADER.  Members 
are  the  unit's  combat  vehicles (TANKS) . 

S. UNIT  (SUPPLY  UNIT).  Owned  by  a  SUPPLY. OFFICER.  Members  are 
the  unit's  supply  vehicles (TANKS) . 

TNK. ALIVE (TANK  ALIVE) .  Owned  by  the  system.  Members  are 
vehicles  still  alive  within  the  simulation. 

Xm2£A£2-gm2U£ 

TANK.  A  temporary  entity  used  to  represent  all  vehicles  on 
the  battlefield.  Its  attributes  distinguish  the 
individual  vehicles  as  to  type  and  function. 

ISfl£2IA£I-ASlfi3SmSUIflI£££aL 
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AMM05  (AMMUNITION  5). 

AMM06 (AMMUNITION  6). 

AP.TOW (ABMOR-PIERCING/TOW)  .  Ammunition  1. 

TAC1 . (TANK  AMMUNITION  CODE  1). 

TAC2. (TANK  ADMONITION  CODE  2). 

TAC3. (TANK  ASHONITION  CODE  3). 

TAC4 . (TANK  AMMUNITION  CODE  4). 

TAC5. (TANK  ADMONITION  CODE  5). 

TAC6 . (TANK  AMMUNITION  CODS  6). 

AW1. OH. BSL3 (ALTERNATE  WEAPON  1  OB  MISSILE  3).  Amaunition  3. 
AN2 . OR . ADM  (ALTERNATE  WEAPON  2  OR  AIR  DEFENSE  MISSILE). 
Ammunition  4. 

COCDR (COMPANY  COMMANDER).  Of  a  TANK. 

COLOR  This  attribute  of  a  TANK  indicates  the  TANK'S  force 
membership.  "0"  indicates  RED  FORCE,  "1"  indicates  BLUE. 
HE. DRAG (HEAT/DRAGON  ROUNDS).  Ammunition  2. 

MAX. CUBE.  Indicates  the  max  cargo  cube  a  resupply 
vehicle  (TANK)  is  designed  to  more. 

MAX. NT.  Indicates  the  max  cargo  weight  a  resupply 
vehicle (TANK)  is  designed  to  move. 

NAME.  Indicates  the  nuaber  of  a  TANK  in  the  battle. 

PLTLDB (PLATOON  LEADER).  Of  TANK. 

POINTER.  Combat  vehicle's  machine  address. 
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RND.CNTR  (ROUND  COUNTER)  .  Arguaent  of  routine  W. AMMO ( WEAPON 
AMMUNITION)  carrying  the  value  of  the  TANK  updating. 
SL0AD1 (STOWED  LOAD  1) .  Optiaal  load  aaao  type  1. 

SLOAD2 (STOWED  LOAD  2)  .  Optiaal  load  aaao  type  2. 

SLOAD3  (STOWED  LOAD  3) .  Optiaal  load  aaao  type  3. 

SLOAD4  (STOWED  LOAD  4).  Optimal  load  aaao  type  4. 

SLOAD5 (STOWED  LOAD  5) .  Optiaal  load  aaao  type  5. 

SLOAD6 (STOWED  LOAD  6)  .  Optiaal  load  aaao  type  6. 

SUPOPF  (SUPPLY  OFFICER).  Of  TANK. 

SYS.  TYPE  (SYSTEH  TYPE).  Of  TANK. 

TWT (TR UCK  WEIGHT).  Maxiaua  cargo  weight  for  a  vehicle. 

TCU (TRUCK  CUBE) .  Haxiaua  cargo  cube  for  a  vehicle. 

WPN. TYPE  (WEAPON  TYPE).  Of  TANK. 


GLOBAL  VARIABLES  (INTEGER) 

WSTREAM  (WEAPON  RANDOM  NUMBER  STREAM). 

MsaagflT.msEGiai 

RND.CNTR  (ROUND  COUNTER).  Arguaent  of  routine  W. AMMO (WEAPON 
AMMUNITION)  carrying  the  value  of  the  TANK  updating. 
ZSOSiM-LISXIM 


1  ROUTINE  BLU. CREATE 

2  " 

3  DEFINE  I  AS  AN  INTEGER  VARIABLE 

4  PRINT  1  LINE  THUS 

ROUTINE  BLU. CREATE 

5  «» 

6  READ  WBIN.WHAX, WSTREAM 

7  SKIP  2  CARDS 

8  READ  PMIN.PHAX'PSTREAM 

9  SKIP  2  CARDS 

10  READ  CHIN'CMAX'CSTREAH 
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1 1 
12 

13 

14 

15 

16 

17 

18 

19 

20 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

If 

58 

59 

I? 

62 

63 

64 

65 

H 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 


SKI?  2  CARDS 

LIST  WMIN,WMAX,WSTREAM,PMIN,PMAX  , PST BEAM 
LIST  CMIN,CMAX,CSTBEAM 

READ  CNUM. PNOM, SNUB 

SKIP  2  CARDS 

LIST  PNUM.CNUM.SNUM 

CALL  PARAMETERS 

LET  N. COMPANY . COflM ANDES  *  CNUM 

CREATE  EVERY  COMPANY .COMMANDER 

FOR  EVERY  COMPANY. COMMANDER,  DO 

READ  N.CCL. V. ITEMS {COMPANY. COMMANDER) 

READ  S4. OFF  (COMPANY. COMMANDER) 

LIST  N.CCL. V. ITEMS (COMPANY.  COMMANDER) 

LIST  S4. OFF  (COMPANY. COMMANDER) 

LOOP 

SKIP  2  CARDS 

LET  N. PLATOON. LEADER  *  PNUM 
CREATE  EVERY  PLATOON .LEADER 
FOR  EVERY  PLATOON. LEADER.DO 
READ  PCO.CDR  (PLATOON. LEADER) 

READ  N . PCL . V . I TEMS (PLATOON .  LEA  DER) 

LIST  PCO.CDR  (PLATOON. LEADER) 

LIST  N.PCL.V. ITEMS (PLATOON. LEADER) 

FILE  PLATOON. LEADER 

IN  CO. UNIT  (PCO.CDR  (PLATOON.  LEADER) ) 

LOOP 

SKIP  2  CARDS 

LET  N. SUPPLY. OFFICER  *  SNUM 
CREATE  EVERY  SUPPLY. OFFICER 
FOR  EVERY  SUPPLY . OFFICER.DO 
READ  SCO. CDR  (SUPPLY. OFFICER) 

READ  N.SCL. V. ITEMS (SUPPLY. OFFICER) 

LIST  SCO. CDR (SUPPLY. OFFICER) 

LIST  N.SCL. V. ITEMS (SUPPLY. OFFICER) 

SKIP  3  CARDS 
LOOP 

CALL  BASIC. LOAD 
SKIP  2  CARDS 

f  r 

READ  N. TANKS  SKIP  3  CARDS 

FOR  I  »  1  TO  N. TANKS,  DO 
CREATE  A  TANK 

READ  NAME  (TANK)  .COLOR  (TANK)  ,  SIS. TYPE  (TANK)  , 
WPN.TIPE  (TANK)  .AP.  TOW  (TANK),  HE.  DRAG  (TANK)  , 
AW1.OR.MSL3  (TANK)  ,  A82  .OR.  ADM  (TANK)  , 


AN 2. OB. 

AMM05  (TANK)  ,'AMHO"6j( TANK)  , 

SLOADi  (TANK)  ,SLOAD2  (TANK)  ,  SLOA  D3  (TANK 

-  -  - -  rSLOAD6  (TANK 

4  (TAN 
TAC3  ' 


.1; 

ill- 


OH 5  (TANK)  , 
NK)  , 


iMCt  t  1  AD  l\l  |  X  1  iA  U  A  /  •  AAVU  liANDJ  f 

PLTLDR  |TANKj  ,COCDH,(TANK4  fcSUPOFF  (TANK)  , 


MAX. NT  (TANK)  .MAX. CUBE  (TANK) 
IF  SIS. TYPE  (TANK)  EQ  7, 

FILE  TANK  IN  S . UNIT  (SUPOFF 


(TANK)  ) 


ALWAYS 

IF  SYS. TYPE (TANK) 

FILE  TANK  IN  PL1_ 

SCHEDULE  AN  UP . W .AMMO (TANK)  IN  1  MINUTE 
ALWAYS 

FILE  TANK  IN  TNK. ALIVE 


NE  7 

.AT.  UNIT^PLTLDR  (TANK4) 


LET  POINTER  (TANK) "TANK 
LET  TCU (TANK) *  HAX.WT 
LET  TWT]TANK)«  MAX. CO 
SKIP  2  CARDS 
LOOP 
RETURN 


(TANK) 

BE  (TANK) 
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80  END 


EXPLANATION  OF  CODE 

Line  3  Defines  recursive  variables  for  the  routine. 

Line  4  Prints  aessage  to  nark  the  start  of  the  routine. 

Lines  6*13  Bead  and  print  out  data  establishing  ain  and  sax 
times  entities  will  check  their  ammo  status  as  veil  as 
randca  nuaber  streams  for  calculations. 

Lines  15-17  Establish  the  nuaber  of  company  commanders, 
platoon  leaders,  and  supply  officers  to  be  created  in 
the  simulation  and  print  out  the  information  input. 

Line  18  Calls  routine  PASANETEBS. 

Lines  19-27  Create  the  specified  nuaber  of  company 

commanders,  and  read  the  attributes  of  each  and  print 
the  information. 

Lines  29-38  Create  the  specified  nuaber  of  platoon  leaders, 
read  their  attributes,  file  them  in  appropriate  sets  and 
print  the  information. 

Lines  40-48  Create  the  specified  number  of  supply  officers, 
read  their  attributes,  file  them  in  appropriate  sets  and 
print  the  information. 

Line  49  Calls  routine  BASIC. LOAD. 
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Line  52  Heads  the  number  cf  TANKS  to  be  created  for  the 
simulation. 

Lines  53-78  Create  the  specified  number  of  TANKS  read  their 
attributes,  file  them  in  appropriate  sets  and  print  the 
information. 

Line  71  Schedules  an  UP. H. AMMO  event  for  each  TANK  to 
initially  set  ammunition  status. 

D.  ''ROUTINE  PARAMETERS" 

Routine  PARAMETERS  is  called  from  routine  BLU. CREATE  to 
reserve  space  for  and  read  values  into  the  following  arrays: 
HPNLON,  COMLON,  NOMEN,  ROF ,  POP,  and  POD.  Additionally  the 
critical  cutoff  values  for  supply  action  (C.L2MT,  C.L2C, 
C.L2PCT,  and  C.  L1PCT),  the  trip  times  to  and  from  the  supply 
points (MINTRIP  and  MAXTRIP) ,  and  the  random  number  streams 
TSTREAM  and  RSTREAM  are  established. 

SLOBAL.IARIMiigS-ili^Ai 

NOMEN (NOMENCLATURE) .Array  specifying  the  name  of  rounds 
played. 

SLQMkJLMUihU^lUSMUl 

CNUM (COMPANY  NUMBER).  Specifies  the  number  of 
COMPANY. COMMANDERS  created. 
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RCODE (RESUPPLY  CODE)  (2-d) .  Holds  the  pointer  value  for  a 
supply  unit's  SCL . V. ITEMS (SUPPLY  CLASS  V  ITEMS). 

ROF  (RATE  OF  FIRE)  (2-d).  Specifies  the  rates  of  fire  for  the 
six  weapons  of  any  weapon  system. 

RSTREAM  (REStJPPLY  STREAM).  Specifies  the  random  number  stream 
to  be  used  for  resupply  calculations. 

TSTREAM (TRIP  RANDOM  NUMBER  STREAM). 

GLOBAL  VARIABLES  (REAL) 

C.L1PCT  (CRITICAL  LON1  PERCENTAGE).  Holds  the  maximum 

percentage  that  LON1  requisitions  may  be  reduced  to  in 

order  to  release  space  on  a  convoy  for  other  critical 

\ 

L0N1  and  LON2  requests. 

C.L2CU (CRITICAL  L0N2  CUBE).  Holds  the  maximum  percent  of 

cube  LON2  requisitions  may  be  cut  to  in  order  to  release 
space  on  a  convoy  for  other  critical  LGN1  and  LON2 
requisitions. 

C.L2PCT  (CRITICAL  LON2  PERCENTAGE).  Holds  the  maximum 

percentage  that  LON2  requisitions  nay  be  reduced  to  in 
order  to  release  space  on  a  convoy  for  other  critical 
LON  1  and  L0N2  requests. 

C.L2.WT (CRITICAL  L0N2  HEIGHT) .  Holds  the  maximum  percent  of 
cube  L0H2  requisitions  may  be  cut  to  in  order  to  release 


1 49 


space  on  a  convoy  for  other  critical  LON  1  and  L0N2 


requisitions. 


COMLON  (2-a)  (COBP ANY  LEVEL  OF  NEED). 

MAXTRIP  (MAX  TRIP).  The  aariaua  tiae  required  for  a  convoy  to 
reach  its  intended  destination. 


MINT3I P (MIN  TRIP).  The  ainiaua  tiae  required  for  a  convoy  to 


reach  its  intended  destination. 


PLTLON  (2-d)  (PLATOON  LEVEL  OF  NEED). 

POD  (2-d)  (PROBABILITY  OF  DAMAGE) .  For  all  weapon  systeas 
played. 

POF  (2-d)  (PROBABILITY  OF  FIRE).  For  all  weapon  systeas 
played. 

WPNLON  (2-d)  (WEAPON  LEVEL  OF  NEED). 

RECURS IVE  VARIABLES  (INTEGER) 

MAX. CL. V. ITEMS (BAX  NUMBER  OF  CLASS  V  ITEMS  PLAYED). 

N. WPN. TYPES (NUMBER  OF  WEAPON  TYPES). 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 


PROGRAM  LISTING 


ROUTINE  PARAMETERS 

•  • 

PRINT  1  LINE  THUS 
ROUTINE  PARAMETERS 

DEFINE  BAX. CL. V. ITEMS, AND  N. WPN. TYPES 
AS  AN  INTEGER  VARIABLES 
READ  MAX. CL. V. ITEMS 
LIST  MAX. CL. V. ITEMS 
SKIP  3  CARDS 
« « 


RESERVE  WPNLON  (*,*) 
READ  WPNLON 
SKIP  3  CARDS 
LIST  WPNLON 
RESERVE  PLTLON  (*,*) 
READ  PLTLON 
SKIP  3  CARDS 


AS  BAX. CL. V. ITEMS  BY 

AS  MAX. CL. V. ITEMS  BY 


5 

5 
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17  LIST  PLTLON 

18  RESERVE  COMLO N  (* ,*)  AS  MAX. CL. V. ITEMS  BY  5 

19  READ  COMLON 

20  SKIP  2  CARDS 

21  LIST  COSLON 

22  •• 

23  RESERVE  NOMEN  (*)  AS  MAX . CL . V . ITEMS 

24  READ  NcMEN 

25  SKIP  2  CARDS 

26  LIST  NOMEN 

27  *  • 

28  READ  N.WPN. TYPES  LIST  N.mN.  TYPES 

29  •  * 

30  SKIP  3  CARDS 

31  RESERVE  HOP  AS  N.HPN. TYPES  BY  6 

32  READ  HOP 

33  SKIP  3  CARDS 

34  LIST  ROF 

35  " 

36  RESERVE  POP  AS  N.HPN. TYPES  BY  6 

37  READ  POP 

38  SKIP  3  CARDS 

39  LIST  POP 

40  * ' 

41  RESERVE  POD  AS  N.HPN. TYPES  BY  4 

42  READ  POD 

43  SKIP  2  CARDS 

44  LIST  POD 

45  " 

46  "RESERVE  AN  ARRAY  TO  HOLD  RESUPPLY  REQUESTS 

47  RESERVE  RCODE  (*,*)  AS  CNUM  BY  6 

48  " 

49  "  SET  UP  CRITICAL  CUTOFF  VALUES  FOR  S-4 

50  READ  C. L2HT,C.L2CU,C.L2PCT,C.L1PCT 

51  LIST  C.L2WT,C.L2CU,C.L2PCT,C.L1PCT 

52  SKIP  2  CARDS 

53  READ  MINT RIP, MAXTRIP , T ST REAM, RST REAM 

54  LIST  NINTRIP, MAXTRIP ,TSTREAM,RST REAM 

55  SKIP  2  CARDS 

56  " 

57  RETURN 

58  END 

EXPLANATION  OF  CODE 

Line  3  Prints  a  aessage  specifying  the  start  of  the 
routine. 

Lines  4-5  Define  recursive  variables  for  the  routine. 

Lines  6-7  Read  and  print  out  the  sax  number  of  aaaunitioc 
types  to  be  played  in  the  siaulation. 

Lines  10-21  Reserve  space  for  and  read  the  threshold  values 
for  the  level  of  need  played  at  the  weapon,  platoon,  and 


coapany  levels  in  the  siaulation. 
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Lines  23-26  Reserve  an  array  for  and  read  in  the 
nomenclatures  played. 

Line  28  Reads  the  number  of  weapon  types  played. 

Lines  31-44  Reserve  space  for,  assign  values  to,  and  print 
out  the  arrays  used  in  the  battle  computations.  These 
arrays  are:  Rate  of  Fire;  Probability  of  Fire;  and 
Probability  of  Damage. 

Lines  46-47  Reserve  space  to  hold  values  of  resupply 

requisitions  created  by  each  company  in  the  simulation. 
Lines  49-51  Read  in  the  critical  cutoff  values  for  resupply 
action.  These  values  are:  Critical  LON2  weight; 

Critical  LON2  cube;  Critical  L0N2  Percent;  and  Critical 
LON  1  percent. 

Lines  53-54  Read  in  the  min  and  max  tines  required  to 
travel  between  the  supply  point  and  the  company. 

E.  "ROUTINE  BASIC. LOAD" 

Routine  BASIC. LOAD  is  called  from  routine  BLD. CREATE  to 
create  the  base  ammunition  assets  of  all  platoons, 
companies,  and  supply  officers  in  the  model. 

EVENTS  CALLED 

UP.COH. AHHO (UPD ATE  COMPANY  AHHO) . 

UP. PLT.AHHO (UPDATE  PLATOON  ANNO). 


GLOBAL  VARIABLES  ( ALPHA) 

NOHEN  (NOMENCLATURE)  .  Specifies  name  of  round. 

GLOBAL  VARIABLES  (INTEGER) 

CCODE (COMPANY  CODE)  (2-d) .  Holds  the  pointer  value  for  a 
company*  s  CCL. V. ITEMS (COMP ANY  CLASS  V  ITEMS). 

CNUM (COMPANY  N0MBER) .  Specifies  the  number  of 
COMPANY. COMMANDERS  created. 

PCODE  (PLATOON  CODE)  (2-d)  .  Holds  the  pointer  value  for  a 
platoon's  PCL.V. ITEMS (PLATOON  CLASS  Y  ITEMS). 

PNOM (PLATOON  NUMBER) . 

SCODE  (SUPPLY  CODE)  (2-d).  Holds  the  pointer  value  for  a 
supply  unit’s  SCL.Y.lTEMs(SOPPLY  CLASS  V  ITEMS). 

SNOM (NUMBER  OP  SUPPLY  OFFICERS). 

PERMANENT  ATTRIBUTES  (INTEGER) 

N. CCL. v. ITEMS.  Number  of  company  class  V  items (UNIQUE  TO  A 
COMPANY. COMMANDER) . 

N.PCL. Y. ITEMS.  Number  of  platoon  class  V  items(UNIQUE  TO  A 
PLATOON. LEADER) . 

N.SCL.Y. ITEMS.  Number  of  supply  class  V  items  (UNIQUE  TO  A 
SUPPLY. OFFICER)  . 

BS£flgsiYE_Y&siAfiI«£§-imgSSfil. 

C,I,P,S  -  Loop  indicies. 

SETS  USED 
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CO. AMMO  (COMPANY  AMMUNITION).  Owned  by  a  COMPANY. COMMANDEB. 
Members  are  the  unit's  CCL . V. ITEMS (COMPANY  CLASS  V 
ITEMS) 

PLT. AMMO  (PLATOON  AMMUNITION).  Owned  by  a  PLATOON. LEADEB. 
Members  are  the  unit's  PCL. V. ITEMS (PLATOON  CLASS  V 
ITEMS) 

S. AMMO (SUPPLY  AMMUNITION).  Owned  by  a  SUPPLY . OPPICEB. 

Members  are  the  unit's  SCL.V. ITEMS (SUPPLY  CLASS  V  ITEMS) 
TEMPORARY  ENTITIES 
CCL. V. ITEM. (COMPANY  CLASS  V  ITEM). 

PCL. V. ITEM. (PLATOON  CLASS  Y  ITEM). 

SCL.V.  ITEM.  (SUPPLY  CLASS  V  ITEM). 

C.RND.  CNTR  (COMPANY  BOUND  COUNTER) .  Argument  for  event 
UP. COM. AMMO  (UPDATE  COMPANY  AMMUNITION)  holding  a 
pointer  of  a  company  unit. 

CNOMEN  (COMPANY  NOMENCLATURE).  This  attribute  of  a 

CCL. V. ITEM (COMPANY  CLASS  V  ITEM)  contains  the  name  of 
the  particular  ammunition. 

PNOHEN  (PLATOON  NOMENCLATURE).  This  attribute  of  a 

PCL. V. ITEM (PLATOON  CLASS  V  ITEM)  contains  the  name  of 
the  particular  ammunition* 
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SN0M3N (SUPPLY  NOMENCLATURE) .  This  attribute  of  a 

SCL. V. ITEM (SUPPLY  CLASS  V  ITEM)  contains  the  name  of  whs 
particular  ammunition. 

TEMPORARY  ATTRIBUTES  (INTEGER) 

CAC  (COMPANY  AMMUNITION  CODE). 

ONHAND  (INTEGER).  This  attribute  of  a  SCL. Y. ITEM (SUPPLY 

CLASS  Y  ITEM)  holds  the  on-hand  balance  of  stocks  for  an 
ammunition. 

P.RND.CNTR  (PLATOON  ROUND  COUNTER).  Argument  of  the  event 
UP. PLT. AMMO (UPDATE  PLATOON  AMMUNITION)  carrying  the 
pointer  value  of  the  platoon  currently  updating. 

PAC (PLATOON  AMMUNITION  CODE).  Of  a  PCL. V .ITEM  (PLATOON  CLASS 
V  ITEM) 

RDS. PKG  (ROUNDS  PER  PACKAGE).  Number  packed  per  pallet  of  an 
SCL. Y, ITEM (SUPPLY  CLASS  Y  ITEM). 

SAC (SUPPLY  AMMUNITION  CODE). 

CU. PKG (CUBE  PACKAGE).  Cube  of  ammo  pallet  for  an  SCL. Y. ITEM 
(SUPPLY  CLASS  Y  ITEM) . 

NT. PKG  (HEIGHT  PACKAGE).  Height  of  ammo  pallet  for  an 
SCL.  Y.  ITEM  (SUPPLY  CLASS  Y  ITEM). 

PROGRAM  LISTING 

1  ROUTINE  BASIC. LOAD 

2  DEFINE  I,P,S,AND  C  AS  INTEGER  VARIABLES 
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PRINT  1  LINE  THOS 
ROUTINE  BASIC. LOAD 


•» SETUP  PLATOON  BASIC  LOADS 
RESERVE  PCODEJ*,*)  AS  PNUH  BY  * 

POR  P  =  1  TO  PNUN.  DO 

RESERVE  PCODE (PNUN ,*)  AS  N.PCL. V. ITEMS (P) 
FOR  I  *  1  TO  N.PCL.V. ITEMS (P)  ,  DO 

CREATE  A  PCL.V.ITEM  CALLED  PCODE (P, I) 

LET  PAC  (PCODE  (P,  I))  *  I 

LET  P NOHEN  (PCODE  (P ,1)1  *  NOHEN  (I) 

FILE  PCODE  (P, I)  IN  PLI.AMHO(P) 

LOOP 

SCHEDULE  A  UP. PLT. AHHO (P)  IN  1  HINUTE 
LOOP 

t » 

••SETUP  COHPANY  BASIC  LOADS 
RESERVE  CCODEJ*,*)  AS  CNUH  BY  * 

FOR  C=1  TO  CNUH,  DO 

LIST  C.CNOM.N.CCL. V.  ITEMS  (C) 

RESERVE  CCODB(CNUM,*)  AS  N.CCL.V.  ITEMS  (C) 
POR  I  *  1  TO  N.CCL.V.ITEMS (C) ,  DO 

CREATE  A  CCL.  V .ITEM  CALLED  CCODE  (C, I) 

LET  CAC  (CCODE  (C.I)  )  =  I 

LET  CNOMEN  (CCODE  (C,I))  *  NOMEN  (I) 

PILE  CCODE  (C, I)  IN  CO.  AMMO  (C) 

LOOP 

SCHEDULE  AN  OP.COM.AHMO(C)  IN  1  MINUTE 
LOOP 

i  • 

••  SETUP  SUPPLY  OFFICER  B1SIC  LOADS 
RESERVE  SCODE  (*,*)  AS  SNUM  BY  * 

FOR  S=1  TO  SNUM,  DO 

LIST  S.SNQM . N. SCL. V. ITEMS (S) 

RESERVE  SCODE  (SNUM  ,* )  AS  N.SCL  .V.  ITEMS  (S) 
FOR  I  *  1  TO  N.SCL.V. ITEMS (S)  ,  DO 

CREATE  A  SCL . V. ITEM  CALLED  SCODE  (S, I) 
LET  SAC  (SCODE (S. I)  )  *  I 


S.Il)  *  NOHEN  (I) 

!(S, if)  »CU.  PKG  fsfcODE  (S.XH 

M:tU6?SfAiA(SCODi(4'4r 


READ  NT. PKG (SCODE ( 
READ  RDS. PKG (SCODE 
FILE  SCODE  (S, I)  IN 
LOOP 
LOOP 
RETURN 
END 

EXPLANATION  OF  CODE 


Line  2  Defines  recursive  variables  used  in  the  routine. 
Line  3  Prints  a  aessage  aarking  the  beginning  of  the 
routine. 

Line  6  Reserves  the  first  index  of  the  ragged  array  P CODE 
as  the  nuaber  of  platoons  played  in  the  siaulation. 
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PCODE  will  eventually  hold  the  ammunition  types  used  by 
the  platoon. 

Line  7  Begins  the  outside  loop  over  each  Platoon. Leader  for 
the  code  segment  which  creates  and  stores  the  ammunition 
carried  by  each  platoon.  Loop  ends  on  line  16. 

Line  8  Reserves  the  second  index  of  the  ragged  array  PCODE 
to  hold  the  number  of  ammo  types  carried  by  each 
platoon. 

Line  9  Begins  the  inside  loop  over  each  ammunition  type 
carried  by  a  platoon.  Loop  ends  on  line  14. 

LINE  10-13  Create  each  ammo  type  carried  by  a  platoon, 
record  its  ammunition  code  and  nomenclature,  and  file 
the  ammo  type  in  the  platoon  leader's  ammo 
StoeVs  (PLT. &MH0) . 

Line  15  Schedules  the  initial  update  for  the  platoon. 

Line  1i‘  Reserves  the  first  index  of  the  ragged  array  CCODE 
to  the  number  of  companies  played  in  the  simulation. 
CCODE  will  eventually  hold  the  ammunition  types  used  by 
the  company. 

Line  20  Begins  the  outside  loop  over  each  company 

commander,  the  code  segment  which  creates  and  stores  the 
ammunition  carried  by  each  company.  Loop  ends  on  line 
30. 


( 
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Line  22  Reserves  the  second  index  of  the  ragged  array  CCODE 
to  hold  the  number  of  ammo  types  carried  by  each 
company. 

Line  23-28  Begin  the  inside  loop  over  each  ammunition  type 
carried  by  a  company.  Loop  ends  on  line  28. 

Line  24-27  Create  each  ammo  type  carried  by  a  company; 
record  its  ammunition  code  and  nomenclature;  and  file 
the  ammo  type  in  the  company  ammo  stocks  (CO. ABHO) . 

Line  33  Beserves  the  first  index  of  the  ragged  array  SCODE 
to  the  number  of  supply  elements  played  in  the 
simulation. 

Line  34  Begins  the  outside  loop  over  each  supply  officer, 
the  code  segment  which  creates  and  stores  the  ammunition 
carried  by  each  supply  unit.  Loop  ends  on  line  45. 

Line  36  Reserves  the  second  index  of  the  ragged  array  SCODE 
to  hold  the  number  of  ammo  types  carried  by  each  supply 
unit. 

Line  37  Begins  the  inside  loop  over  each  ammunition  type 
carried  by  a  supply  unit.  Loop  ends  on  line  44. 

Lines  38-43  create  each  ammo  type  carried  by  a  supply  unit; 
record  its  ammunition  code,  nomenclature,  standard 
package  weight,  standard  package  cube,  number  of  rounds 
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per  package,  starring  level,  and  file  them  in  the  supply 

1 

unit's  anno  stocks  (S. AMMO) . 

F.  "SOUTINE  W.AHHO" 

Routine  W.AHHO  is  called  by  events  UP.  W.AHHO, 

CO. HSSOPPLI. ARS,  and  REDISTRIBUTE  for  each  TANK  in  the  model 
in  order  to  update  each  TANK'S  ammunition  LON.  An  argument, 
NO. BATTLE,  is  set  to  indicate  whether  battle  information 
should  be  obtained  or  if  only  a  simple  update  is  required. 
Additionally  a  program  indicator  HFLAG,  is  set  to  provide 
information  on  the  system's  status. 

ARGUMENTS  USED 

A  -  Identifies  the  weapon  system  updating  its  ammunition. 

NO. BATTLE.  Indicates  whether  routine  BATTLE  should  be 
called. 

"0"  indicates  no 
"1"  indicates  yes 

WFLAG.  Weapon  status  indicator.  If  WFLAG=100  the  weapon  is 
out  of  a  particular  ammunition  this  signals  the  platoon 
to  do  an  immediate  update.  If  WFLAG*1  the  TANK  has  been 
knocked  out  of  battle  and  should  no  longer  update  its 
ammunition  status. 

DEFINE  TO  HEAH 

AHHO 1 .  A P . TOW ( ABHOR  PIBBCIMG/TOW  BOUNDS). 

( 
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AMM02.  HE. DRAG (HEAT/DRAGON  BOUNDS). 

AMM03 .  AMI. OB. MSL3 (ALTERNATE  WEAPON  1  OR  MISSILE  3). 
AHM04.  AH2. OH. ADM (ALTEBNATE  WEAPON  2  OB  AIR  DEFENSE 
MISSILE)  . 

GLOBAL  VARIABLES 

HPNLON  (2-d)  (WEAPON  LEVEL  OF  NEED). 


TIME.  V 


I  -  Loop  index. 


TEMP. LON (TEMPORARY  LON).  Place  holder  for  LON  computations. 
THY  Routing  indicator  to  the  ammo  type  being  updated. 


PCT  (PERCENT)  . 

BOOnO?  CALLED 


BATTLE 


AHM05 (AMMUNITION  5).  Of  a  TANK. 

AMM06 (AMMO NIT ION  6).  Of  a  TANK. 

AP. TON (ABMOR-PIERCING/TOV) .  Ammunition  1. 
TAC1.  TANK  AMMUNITION  CODE  1. 

TAC2.  TANK  AMMUNITION  CODE  2. 

TAC3.  TANK  AMMUNITION  CODE  3. 
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TAC4 .  TANK  AMMUNITION  CODE  4. 

TAC5.  TANK  AMMUNITION  CODE  5. 

TAC6 .  TANK  AMMUNITION  CODE  6. 

AW1. OR. MSL3  (ALTERNATE  WEAPON  1  Ofi  MISSILE  3).  Ammunition  3 
of  a  TANK. 

AW2. OH. ADM (ALTERNATE  WEAPON  2  OH  AIH  DEFENSE  MISSILE). 
Ammunition  4  of  a  TANK. 

FKILL (FIREPOWER  KILL).  Indicates  whether  a  TANK  has 

sustained  a  firepower  kill  during  the  battle. 

"0”  indicates  no 
"1 "  indicates  yes 

HE. DRAG (HEAT/DH AGON  ROUNDS).  Ammunition  2  of  a  TANK. 

KKILL (catastrophic  KILL).  Indicates  whether  a  TANK  has 

sustained  a  catastrophic  kill  during  the  battle. 

"0"  indicates  no 
"1"  indicates  yes 

HKILL (MOBILITY  KILL).  Indicates  whether  a  TANK  has  sustained 

a  mobility  kill  during  the  battle. 

"0"  indicates  no 
"I"  indicates  yes 

HFKILL (MOBILITY  AND  FIREPOWER  KILL).  Indicates  whether  a 

TANK  has  sustained  a  mobility  and  firepower  kill  during 
the  battle. 


"0"  indicates  no 
"I"  indicates  yes 

{  OH1 (ON-HAND  1).  Current  balance  of  ammunition  1  on  a  TANK. 
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0H2 (ON-HAND  2).  Current  balance  of  ammunition  2  on  a  TANK. 
OH3  (ON-HAND  3).  Current  balance  of  ammunition  3  on  a  TANK. 
OH4  (ON-HAND  4).  Current  balance  of  ammunition  4  on  a  TANK. 
OHS (ON-HAND  5).  Current  balance  of  ammunition  5  on  a  TANK. 
OH6 (ON-HAND  6).  Current  balance  of  ammunition  6  on  a  TANK. 
POINTER  Machine  address  of  a  TANK. 


PLTLDH (PLATOON  LEADER)  Of  TANK 
SLOAD1 (STONED  LOAD  1) .  Optimal 
SL0AD2 (STONED  LOAD  2).  Optimal 
SLOAD3  (STONED  LOAD  3)  .  Optimal 
SL0AD4  (STONED  LOAD  4)  .  Optimal 
SLOAD5 (STONED  LOAD  5) .  Optimal 
SLOAD6 (STONED  LOAD  6) .  Optimal 
KLON1 (NEAPON  LEVEL  OP  NEED  1). 

NLON2 (NEAPON  LEVEL  OP  NEED  2). 

NLON3 (NEAPON  LEVEL  OP  NEED  3). 

WLON4 (NEAPON  LEVEL  OP  NEED  4) . 

HLON5 (NEAPON  LEVEL  OP  NEED  5). 

HLON6 (NEAPON  LEVEL  OP  NEED  6). 

TANK 

PROGRAM  LISTING 
1  ROUTINE  W.AMHO  GIVEN  A 


load  ammo  type  1. 
load  ammo  type  2. 
load  ammo  type  3. 
load  ammo  type  4. 
load  ammo  type  5. 
load  ammo  type  6. 

Urgency  of  need  ammunition  1. 
Urgency  of  need  ammunition  2. 
Urgency  of  need  ammunition  3. 
Urgency  of  need  ammunition  4. 
Urgency  of  need  ammunition  5. 
Urgency  of  need  ammunition  6. 


AND  NO. BATTLE  YIELDING  NFLAG 
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DEFINE  NO. BATTLE , HFL AG . TEMP. LON  AS  INTEGEB  7 ASIABLES 
DEFINE  PCT  AS  A  BEAL  7 ABIABLE 
DEFINE  A.TRY.  AND  I  AS  AN  INTEGEB  7ABIABLES 
PRINT  2  LINES  KITH  TIDE.?  AND  A  AS  FOLLOWS 
E7BNT  W. AMMO  CALLED  AT  TIME. 7  **.**** 

WEAPON  SYSTEM  ******  OPDATING 

•  i 

IF  NO. BATTLE  EQ  0, 

CALL  BATTLE  (A) 

ALWAYS 

IF  FRILL  (A)  EO  1  OB  KKILL(A)  EQ  1  OB  MKILL(A)  EQ  1 
OB  MESH! (a)  EQ  1 


:.|A^  Eg  I^OB  KKILL(A)  EQ  1  OB  MKILL(A) 

2{l1nE§  BITH  POINTEB  (TANK)  THUS 
LE  DAMAGE  ON  TANK  ******  PBE7ENTS 


PBINT  2  LINES  BITH 
BATTLE  DAMAGE  ON 
AMMO  ASSESSMENT. 


TANK  ******  PBE7ENTS 
SEQUENCE  ENDED. 

BATTLE  DAMAGE  SUSTAINED 


LET  BFLAG  >1  "  BATTLE  DAMAGE  SUSTAINED 

BETOBN 
OTHEBBISE 

•  i 

*  *  CAPTURE  CUBBENT  INFORMATION  FOB  PLT. COMPUTATIONS. 
LET  OH1  (A)*  AMM01  (A) 

LET  OH2  (A)  *  AMMO 2  (A) 


LET  OH1  A)*  AMM01  A) 

LET  OH2  A  =  AMMO 2  A 
LET  OH3  A  =  AMM03  A 
LET  0H4 i A  *  AMM04  A 
LET  0H5  A  *  AMMO 5  A 
LET  OH6  A  *  AMMO 6  A 

« i 

••BEGIN  LON  COMPUTATIONS 
LET  PCT*  AMM0 1  (A)  /SLOAD1  (A) 
LET  I*  TAC1  (A) 

LET  TBY  *  1 
GO  TO  CHECK 

' 1 ' LET  BLON1 (A)-TEMP.LON 
ii 

LET  PCT*  AMMO 2  (A)  /SLOAD2  (A) 
LET  I*  TAC2  (A) 

LET  TBY  *  2 
GO  TO  CHECK 

• 2*LET  BLON2 (A) *TEMP.LON 
« « 

LET  PCT*  AMMO 3  (A)  /SLOAD3  (A) 
LET  I*  TAC3 (A) 

LET  TRY  *  3 
GO  TO  CHECK 

• 3  *  LET  NLOH3 (A) *TEMP .LON 
« • 

LET  PCT*  AHH04  (A)  /SL0AD4  (A) 
LET  I*  TAC4 (A) 

LET  TBY  *  4 
GO  TO  CHECK 

•4 *LBT  WLON4 (A) *TEMP.LON 
*  • 

LET  PCT*  AMH05  (A)  /SLOAD5  (A) 
LET  I*  TAC5 (A) 

LET  TBY  *  5 
GO  TO  CHECX 

•5 *LBT  WLON5 (A)*TEMP.LON 

LET  PCT*  AHH06  (A)  /SLOAD6  (A) 
LET  I*  TAC6 (A) 

LET  TBY  *  6 
GO  TO  CHECK 

•6 'LET  WLON6 (A) *TEHP .LON 
GO  TO  7 

« i 

•CHECK' 

IF  PCT  GE  WPNLON (1,1) , 

LET  TEMP. LON*  5 
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66 

GO  TO  ROUTING 

67 

ALWAYS 

68 

•  i 

1,2) 

69 

IF  PCT  GE  VPN  LON  ( 

70 

LET  TEMP . LON*  4 

71 

GO  TO  ROUTING 

72 

ALWAYS 

73 

•  i 

74 

IF  PCT  GE  WPNLONf 

1.3) 

75 

LET  TEMP. LON*  3 

76 

GO  TO  ROUTING 

77 

ALWAYS 

78 

« « 

79 

IF  PCT  GE  WPNLON  ( 

1,4) 

80 

LET  TEMP. LON*  2 

81 

GO  TO  ROUTING 

82 

ALWAYS 

83 

i « 

84 

IF  PCT  GE  WPNLONj 

1,5) 

85 

LET  TEMP. LON*  1 

86 

LET  WFLAG  *  100 

87 

AL WAYS 

88 

•ROUTING*  GO  TO  1 

,2,3 

39 

•7* 

90 

RETURN 

91 

END 

EXPLANATION  Of  CODE 


Lines  2-4  Define  recursive  variables  used  in  the  routine. 


Line  5  Prints  a  message  narking  the  start  of  the  event  and 
identifying  the  weapon  systen  updating. 

Lines  7-9  Check  if  battle  infornation  should  be  obtained, 
and  call  routine  BATTLE  to  obtain  this  current 
infornation . 


Lines  10-15  Check  if  battle  damage  has  been  sustained, 

print  a  message  if  damage  has  been  incurred  and  end  the 
routine  without  action. 

Lines  17-23  Update  the  current  knowledge  of  the  ammo 
situation  on  the  weapon  system. 
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Lines  25-61  Sequentially  address  each  ammo  type  carried  on 
a  weapon  system;  determine  a  percent  fill;  temporarily 
transfer  control  to  ' CHECK ’ (line  63)  in  order  to 
determine  the  correct  LON  to  be  assigned;  and  assign  an 
LON . 

Lines  63-89  Receive  a  percent  value  from  lines  25-61  and 
match  this  percent  to  that  type  of  weapon’s  LON  array. 
Pass  the  LON  value  determined  back  to  lines  25-61  for 
assignment. 

G.  "ROUTINE  P. CLASS. 7" 

Soutine  P. CLASS. T  is  called  by  events  UP.PLT.AMMO, 

CO. RESUPPLY. ARE,  and  REDISTRIBUTE  for  each  platoon  played  in 
the  model  to  update  their  ammunition  LONs  according  to  the 
latest  weapon  LON  information.  Additionally,  a  program 
indicator,  P?LAG,  is  set  to  provide  information  on  the 
platoon's  status. 

ARGUMENTS 

J  -  Argument  for  routine  P. CLASS. V  specifying  the  platoon 
currently  updating. 

PFLAG.  Platoon  status  indicator: 

PFLAG  *  1  -  indicates  that  the  platoon  is  out  of  stock 
for  an  ammo  type  and  signals  the  company  to  update  its 
ammo  status. 
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P?LAG  =  N.PCL.VITEMS  -  indicates  that  the  platoon  has  no 
need  for  more  ammo.  That  is,  the  platoon's  weapons 
have  been  destroyed  or  danaged. 

GLOBAL  VARIABLES  (INTEGER) 

PCODE  (PLATOON  CODE)  (2-d)  .  Holds  the  pointer  value  for  a 
platoon's  PCL.V. ITEMS (PLATOON  CLASS  V  ITEMS). 

TANK 

PLTLON  (PLATOON  LEVEL  CF  NEED)  (2-d)  . 

TIME.? 

PERMANENT  ATTHIBOTES  (INTEGER) 

N.PCL.V. ITEMS. (SOMBER  OF  PLATOON  CLASS  V  ITEMS) .  Unique  to  a 
PLATOON. LEADER. 

MSgB§Ivq_VMIl£i»^ _ limSfiSL 

I  -  Loop  index. 

RECURSIVE  VARIABLES.  (REAL) 

PCT  (PERCENT) .  Place  holder  for  calculations. 

£Oomi_£AItlI£ 

P. CLASS. V 

sm_g£l£ 

PLAT. UNIT (PLATOON  UNIT).  Owned  by  a  PLATOON . LEADER.  Meabers 
are  the  unit's  cosbat  vehicles (TANKS) . 
TEMPORARY-AITBlggllS  .IIMIB6EBL 
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TAC1 .  TANK  AMMUNITION  CODE  1. 
TAC2.  TANK  AMMUNITION  CODE  2. 
TAC3 .  TANK  AMMUNITION  CODE  3. 


TAC4.  TANK  AMMUNITION  CODE  4. 

TAC5 .  TANK  AMMUNITION  CODE  5. 

TAC6 .  TANK  AMMUNITION  CODE  6. 

FKILL (FIREPOWER  KILL).  Indicates  whether  a  TANK  has 

sustained  a  firepower  kill  during  the  battle. 

"0"  indicates  no 
"1W  indicates  yes 

KKILL (CATASTROPHIC  KILL)  .  Indicates  whether  a  TANK  has 

sustained  a  catastrophic  kill  during  the  battle. 

"0"  indicates  no 
"1"  indicates  yes 

MFKILL (MOBILITY  &  FIREPOWER  KILL).  Indicates  whether  a  TANK 
has  sustained  a  aobility  &  firepower  kill  during  the 
battle. 

"0"  indicates  no 
"I*  indicates  yes 

HKI IMMOBILITY  KILL).  Indicates  whether  a  TANK  has  sustained 
a  aobility  kill  during  the  battle. 


"0"  indicates  no 
"1"  indicates  yes 


OH1  (ON-HAND 

1)  .  Current 

balance 

of 

aaaunition 

1 

on 

a 

TANK. 

OH2 (ON-HAND 

2) .  Current 

balance 

of 

aaaunition 

2 

on 

a 

TANK. 

0H3  (ON-HAND 

3).  Current 

balance 

of 

aaaunition 

3 

on 

a 

TANK. 
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0H4 (ON-HAND  4).  Current  balance  of  ammunition  4  on  a  TANK. 

OH5 (ON-HAND  5).  Current  balance  of  ammunition  5  on  a  TANK. 

0H6 (ON-HAND  6).  Current  balance  of  ammunition  6  on  a  TANK. 

P.  SHORT  (PLATOON  SHORTAGE).  Current  shortage  of  a  PCL.V.ITEM 

(PLATOON  CLASS  V  ITEM) .  Unique  to  each  platoon  and  ammo 
type. 

P.CHBT. LOSS (PLATOON  COMBAT  LOSS).  Indicates  that  the  loss  of 
a  platoon  weapon  system  negates  the  need  for  this  ammo 
type. 

PAHMO. LON (PLATOON  AMMO  LEVEL  OF  NEED).  Unique  for  each 
platoon  and  ammo  type. 

PCURR.  LOAD  (PLATOON  CURRENT  LOAD).  On-hand  balance  of  ammo. 
Unique  for  each  platoon  and  weapon  type. 

PL. 3. LOAD (PLATOON  BASIC  LOAD).  Optimal  load  for  a  PCL.V.ITEM 
(PLATOON  CLASS  V  ITEM)  . 

SLOAD1  (STONED  LOAD  1)  .  Optimal  load  ammo  type  1. 

SLOAD2 (STONED  LOAD  2).  Optimal  load  ammo  type  2. 

SLOAD3 (STONED  LOAD  3) .  Optimal  load  ammo  type  3. 

SLOAD4  (STONED  LOAD  4).  Optimal  load  ammo  type  4. 

SLOAD5  (STONED  LOAD  5).  Optimal  load  ammo  type  5. 

SLOAD6  (STONED  LOAD  6).  optimal  load  ammo  type  6. 

PROGRAM  LISTING 

1  ROUTINE  P. CLASS. V  GIVEN  J  YIELDING  PFLAG 
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DEFINE  I.PFLAG.AND  J  AS  INTEGER  VARI ABLES 
DEFINE  PCT  AS  A  BEAL  VARIABLE 
PRINT  1  LINE  WITH  TIME.V  AS  FOLLOWS 

EVENT  PLT. AMMO  CALLED  AT  TIME. V  **.**** 


FOB  1  =  1  TO  N.  PCL.V. ITEMS  (J) 
LET  PCURR.LOAD (PCODE  (J.I) 
LET  PL. B. LOAD  (PCODE  (J  ,1)  j 
FOB  EVERT  TANK  IN  PLAT. UN 

0  AND 
0,  DO 


WITH  MKILL 
AND  MFKILL 


(TANK) 

(TANK) 


z  DO 
)  -  0 

hm 


L  (TANK) 


IF  TAC1  (TANK)  =1 
ADD  OH1  (TANK)  TO 
IF  PKILL  (TANK)  EQ 
ADD  SLuAD  1  (TANK 
ALWAYS 

GO  TO  SHORTAGE 
OTHERWISE 


PCURR. LOAD (PCODE (J,I)  ) 

0.  "NO  FKILL 
)  TO  PL.  B .  LOAD  (PCODE  ( J  ,  I) ) 


IF  TAC2 


ADD  OH2  (TANK)  TO  PCOR 
IF  FKILL  (TANK)  BO  0, 
ADD  SLOAD2  (TAN*)  TO 


ALWAYS 

GO  TO  SHORTAGE 
OTHERWISE 


PCURR.  LOAD  (PCODE  (J, I)  ) 

)  $0  PL.  B. LOAD  (PCODE  (J,  I)) 


IF  TAC3 (T ANK)  =1 
ADD  OH3  (TANK) 
IF  FKILL  (TANK) 
ADD  SLOAD3 (T 
ALWAYS 

GO  TO  SHORTAGE 
OTHERWISE 

IF  TAC4  (TANK)  *  I 


K)  TO  PCURR.  LOAD  (PCODE  (J, I)  ) 

NK)  EQ  0, 

3  (TANK)  TO  PL.  B. LOAD  (PCODE (J, I)) 


ADD  0H4  (TANK)  TO  PCURR. LOAD (PCODE (J, I)  ) 

IF  FKILL  (TANK)  EQ  0, 

ADD  SL0AD4  (TANK)  to  PL.  B. LOAD  (PCODE  (J , I) ) 


ALWAYS 

GO  TO  SHORTAGE 
OTHERWISE 


IF  TAC5  (TANK)  =1 
ADD  OH5  (TANK[  TO 
IF  FKILL  (TANK)  E 
ADD  SLOAD5  (TAN 
ALWAYS 

GO  TO  SHORTAGE 
OTHERWISE 


IF  TAC6  (T  ANK)  =1 
ADD  OH6  (TANK)  TO 
IF  FKILL  (TANK)  E 
ADD  SLOAD6  (TAN 
ALWAYS 
ALWAYS 


PCURR.  LOAD  (PCODE  (J,I)  ) 

)  to  PL.  B.  LOAD  (PCODE  (J ,  I) ) 


PCURR.  LOAD  (PCODE  (J, I)  ) 

)  TO  PL.  B. LOAD  (PCODE  (J,  I) ) 


•SHORTAGE* 

LET  P.  SHORT  (PCODE  (J,  I)  ) 
LOOP 

• « 

"CHECK  FOR  BATTLEDAHAGE 
IF  PL.  B.  LOAD  (PCODE  (J  .1) ) 
LET  PFLAG  »  PFLAG* 1 


-  PL. B. LOAD (PCODE (J.I)  ) 
•  PCURR.LOAD  (PCODE  (J, I)  ! 


EQ  0, 


LET  P.  SHORT  (PCODE  (J,  I) )  *  0 
IF  P.CMBT.  LOSS  (PCODE  (J,  I))  EQ  0, 
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LET  P . CMBT. LOSS (PCODE (J# I)  )  *  1 
PRINT  2  LIMES  WITH  I,  J  THUS 

BATTLE  DAMAGE  HAS  NEGATED  THE  MEED  FOB 
AMMO  IN  PLATOON  ** 

ALWAYS 

CYCLE 

OTHERWISE 

i « 

LET  PCT*  PC URR. LOAD (PCODE (J,I) ) 

/PL. B. LOAD  (PCODE  (J,I) ) 

IF  PCT  GE  PLTLON  (1,1), 

LET  PAMMO.LON(FC6dE(J,I))*5 
CYCLE 
ALWAYS 

IF  PCT  GE  PLTLON  (1*2), 

LET  PAMMO.LON (PCODE  (J,I) ) s4 
CYCLE 
ALWAYS 

IF  PCT  GE  PLTLON  (1.3), 

LET  PAMMO.LON (PCODE (JrI)  )  =3 
CYCLE 
ALWAYS 

IF  PCT  GE  PLTLON  (1,4)  • 

LET  PAMMO.LON  (PCODE  («J,I)  )  =2 
CYCLE 
ALWAYS 

IF  PCT  GE  PLTLON  (1 ,5), 

LET  Pi MMO . LON (PCODE (J, I) )  =1 
LET  PFLAG  *  100 
ALWAYS 
LOOP 
RETURN 
END 


Lines  2-3  Define  recursive  variables  used  in  the  routine. 

Line  4  Prints  out  a  aessage  to  aark  the  start  of  the 
routine. 

Line  5  Starts  the  outside  loop  over  all  the  aaao  types 
carried  by  the  platoon.  Loop  ends  on  line  98. 

Lines  6-7  Zero  out  the  platoon  on-hand  aaaunition  and  basic 
load  aaaunition  fcr  the  update. 

Lines  8-10  Begin  the  inner  loop  over  all  TANKS  in  the 

platoon  in  order  to  obtain  the  aost  current  inforaation 
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available  on  each  TANK.  The  loop  ends  on  line  62. 

Note:  the  information  obtained  froa  each  TANK  is 
•’current  knowledge”  from  its  on-hand  attributes.  This 
is  what  the  TANK  "knows"  it  has  on-hand.  Opposite  to 
this  is  "perfect  knowledge"  froa  its  AMMO 1-AMM06 
attributes,  which  is  what  the  TANK  actually  has  on-hand. 

Lines  12-57  Cycle  the  index  over  the  six  possible  choices 
on  the  TANK  until  identification  or  lack  of 
identification  of  the  aaao  code  being  considered  is 
aade.  If  identification  is  nade,  the  on-hand  balance  of 
the  TANK'S  known  load  is  added  to  the  platoon  balance. 

If  the  weapon  system  is  not  F-KILLed  the  base  load  of 
the  TANK'S  aaao  is  added  to  the  platoon  base  load.  Base 
load  is  used  in  determining  how  much  should  be  ordered. 
If  the  weapon  has  been  F-KILLed  the  weapon's  base  load 
is  ignored.  This  lowers  the  aaount  of  aaao  the  platoon 
needs  to  have  on-hand  to  keep  its  systems  full.  After 
updating,  control  is  transferred  to  the  shortage  loop, 
lines  59-60 

Lines  59-61  Provide  a  running  update  of  the  aaount  of  aaao 
the  platoon  is  short  as  the  update  continues  over  all 
the  weapon  systems  in  the  platoon. 
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Line  62  Closes  the  loop  for  a  TANK ,  transferring  control 

either  to  line  8  to  evaluate  the  next  TANK  for  this  aano 
type  or  out  to  complete  the  LON  computation  for  the  ammo 
type. 

Lines  64-73  Check  for  a  zero  base  load  balance  in  the 
platoon's  ammo.  A  new  zero  balance  indicates  that 
battle  damage  to  platoon  weapons  has  negated  the  need 
for  further  requisitioning  of  that  type  of  ammo.  A 
message  is  printed  identifying  the  round  type.  Further 
requisitions  for  this  ammo  type  would  not  be  made. 

Lines  75-76  Compute  the  percentage  of  fill (on-hand/base 
load)  for  an  ammo  type. 

Lines  78-97  Cycle  the  percentage  over  the  five  possible  LON 
threshold  values  until  the  correct  value  is  found  and 
assigned. 

Lina  98  Closes  the  major  loop  in  the  routine  and  transfers 
control  back  to  line  5  in  order  to  update  the  next  ammo 
type, 

H.  "ROUTINE  COM.  AMMO" 

Routine  COM. AMMO  is  called  by  events  UP. COM. AMMO  and 

CO. RESUPPLY. ARR  for  each  company  played  in  the  model  to 

update  ammunition  LONs  according  to  the  most  recent  platoon 


4 

? 
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LON  information.  An  argument,  NO. BATTLE,  is  set  to  indicate 
whether  RES.REQs  should  be  filed  or  whether  a  simple  update 
is  sought.  Additionally,  a  program  indicator,  CFLAG,  is  set 
to  provide  information  on  the  system's  status. 

ARGOMENTS  USED 

C  -  Argument  of  COM. AMMO  (COMPANY  AMMUNITION)  holding  the 
pointer  value  of  the  company  currently  updating. 

CFLAG.  Company  status  indicator;  CFLAG  *  N.CL.V.XTEH 

indicates  that  the  company  has  no  need  for  ammunition. 
That  is,  the  company's  weapons  have  been  damaged  or 
destroyed. 

NO. BATTLE.  Indicates  whether  SES.BEQs  should  be  filed. 

"0"  indicates  no 
"I"  indicates  yes 
EVENTS  SCHEDULED 

UP.S4. AMMO  (UPDATE  S~4  AMMUNITION)  . 

NOHEN (NOMENCLATURE) .  Specifies  name  of  round. 

CCODE  (COHPANT  CODE)  (2-d)  .  Holds  the  pointer  value  for  a 
company's  CCL. V.ITEHs (COMPANY  CLASS  V  ITEMS). 

PC  ODE  (PLATOON  CODE)  (2-d).  Holds  the  pointer  value  for  a 
platoon's  PCL. V.ITEHs (PLATOON  CLASS  V  ITEMS). 


PLATOON. LEADER 


RCODE (RESUPPLY  CODE)  (2-d).  Holds  the  pointer  value  for  a 
resupply  unit's  SCL. 7. ITEMS (SUPPLY  CLASS  V  ITEMS). 

TSTREAM  (TRIP  RANDOM  NUMBER  STREAM) 

COMLON (2-d) (COMPANY  LEVEL  OF  NEED) . 

aoiiunm^jsmi 

MAXTRIP (MAX  TRIP).  The  aaxiaua  tiae  required  for  a  convoy  to 
reach  its  intended  destination. 

MINTRI P  (MIN  TRIP).  The  ainiaua  tine  required  for  a  convoy  to 
reach  its  intended  destination. 


TIME. V 

ssmsssi-mmsm-iifiifism 

N.CCL. V. ITEMS (NUMBER  OF  COMPANY  CLASS  V  ITEMS).  Unique  to  a 
Unit. 


REQN (REQUISITION) . 

S4. OFP (Coapany  S-«  OFFICER). 


COUNT.  Indicates  if  a  resupply  requisition  has  been  filed. 
I  -  Loop  index. 


BE  CURSIVE  VARIABLES.  (REAL) 
PCT  (PERCENT)  . 


UNIFORM . F 


SETS  PS  ED 

CO. UNIT  (COMPANY  UNIT).  Owned  by  a  COMPANY. COMMANDER. 

Members  are  the  unit's  PLATOON. LEADERS. 

CWANT. LIST  (COMPANY  WANT  LIST).  Contains  a  listing  of  the 
resupply  requests  outstanding  for  the  company. 

TEMPORARY  ENTITIES 

RES.R2Q (RESUPPLY  REQUEST). 

TEMPORARY  ATTRIBUTES  (ALPHA) 

RNOMEN (RESUPPLY  NOMENCLATURE). 

C.CMBT.  LOSS  (COMPANY  COMBAT  LOSS).  Indicates  that  the  loss  of 
a  company  weapon  system  negates  the  need  for  this  ammo 
type. 

C.NUM.REQN  (NUMBER  OP  COMPANY  REQUISITIONS).  Total  number  of 
RES.REQs  submitted  for  an  SCL.V.ITEM. 

C. SHORT  (COMPANY  SHORTAGE).  Total  rounds  short  for  a  type 
ammo. 

CAHMO. LON (COMPANY  AMMUNITION  LEVEL  OP  NEED). 

CCURR. LOAD  (COMPANY  CURRENT  LOAD).  On-hand  balance  for  an 
ammo  type. 

CO. B. LOAD (COMP ANY  BASIC  LOAD).  Optimal  load  for  am  ammo 
type. 
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ISSUES.  Argument  of  UP. S4. AMMO  (UPDATE. S4 .AMMUNITION)  holding 
the  pointer  of  the  requesting  unit. 

ISSUES  .  Argument  of  UP. S4.ANN0  (UPDATE.  S4 .  AMMUNITION)  holding 
the  pointer  of  the  unit  supply  officer. 

PCURH. LOAD  (PLATOON  CURRENT  LOAD).  On-hand  balance  for  an 
ammo  type. 

PL. B. LOAD (PLATOON  BASIC  LOAD).  Optimal  load  for  an  ammo 


type. 

RAC (RESUPPLY  AH HO  CODE).  Of  a  RES.  REQ  (RESUPPLY  REQUEST). 
REQUESTOR.  Of  a  RES. REQ (RESUPPLY  REQUEST).  Contains  the 
pointer  of  the  unit  reguesting. 

RQTY (REQUIRED  QUANTITY).  Of  a  RES. REQ (RESUPPLY  REQUEST). 


SPRIORITY (SUPPLY  PRIORITY).  Of  a  RES. REQ (RESUPPLY  REQUEST). 

temporary.  imams-iasiM. 

TlilE.  Of  creation  of  request. 


PROGRAd  LISTING 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 
19 


ROUTINE  COB. ANNO  GIVEN  C, NO. BATTLE  YIELDING  CPLAG 

DEFINE  NO. BATTLE, I.COUNT, CFLAG, AND  C 

AS  INTEGER  VARIABLES 

DEFINE  PCT  AS  A  REAL  VARIABLE 

PRINT  1  LINE  WITH  TIHE.V  AS  FOLLOWS 

EVENT  CON. AHflO  CALLED  AT  TINE.  V  •*.**•* 

« • 

FOR  1*1  TO  N.CCL.V.ITEHS  (C)  ,DO 
LET  CCURR.LOAD  (CCODE  (Cil)  )  *  0 
LET  CO. B. LOAD  (CCODE  (C, if) *  0 
FOR  EVERY  PLATOON.  LEADER  IN  CO.UNIT(C)  ,DO 
ADD  PCURB.  LOAD  (PCODE  (PLATOON  .LEADER,  I) ) 

TO  CCURR.LOAu (CCODE (C.I)  ) 

ADD  PL. S. LOAD (PCODE (PLATOON. LEADER, I) ) 

TO  CO.B.  LOAD  (CCODE  (C, I)) 

LOOP 

IP  CO.B.  LOAD  (CCODE  (C.I))  *  0, 

LET  CFLAG  *  CFLAG  ♦  V 
IF  C. CHBT. LOSS  (CCODE ]C, I) )  *  0 
LET  C.CNBT. LOSS(CCOD£ (C.I)  )  *  1 
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20 


21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

W 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 


PRINT  2  LINES  WITH  I,  C  THUS 

BATTLE  DAMAGE  HAS  NEGATED  THE  NEED  FOR 
AMMO  »**  IN  COMPANY  ** 

ALWAYS 
CYCLE 
OTHER WIS E 

LET  PCT=CCURR.  LOAD  (CCODE  (C,I)  ) 

/CO .  B.  LOAD  (C  CODE  (C,I)) 

IF  PCT  GE  COMLON  (1,1), 

LET  CAMMO.LON (CCODE  (C,I) ) =5 
GO  TO  SHORTAGE 
ALWAYS 

IF  PCT  GE  COMLON  (1,2)  , 

LET  CAMMO. LON (CCODE  (C,I)) =4 
GO  TO  SHORTAGE 
ALWAYS 

IF  PCT  GE  COMLON  (I  ,3)  , 

LET  CAMMO . LON (CCODE (C,l)  ) =3 
GO  TO  SHORTAGE 
ALWAYS 

IF  PCT  GE  COMLON  (1 ,4 )  , 

LET  CAMMO.LON (CCODE  (C, I)) =2 
GO  TO  SHORTAGE 
ALWAYS 

IF  PCT  GE  COMLON  (I  .5)  , 

LET  CAMMO.  LON  (CCODE  (C, I)  )=1 
ALWAYS 

•SHORTAGE* 

LET  C. SHORT (CCODE (C, I)  )  *  CO. B .LOAD (CCODE (C, I) ) 

-  CCURR.  LOAD  (CCODE  (C,  I)  ) 


•  i 


•  • 


'RESUPPLY* 

*•  CHECK  IP  RESUPPLY  NEEDED 

IF  CAMMO.LON  (CCODE  (C  ,1) )  GE  5  OR  NO.  BATTLE  EQ  1 
GO  TO  LOOPT 
OTHERWISE 

"IF  A  PRIOR  LON  IS  EQUAL  TO  THE  CURR  LON,  CYCLE. 


•  < 


FOR  EACH  RES. RE 
WITH  RAC  (RES. RE 
IF  SPRIORITY 
GO  TO  LOOPf 
OTHERWISE 
'LOOP 3*  LOOP 


IN  CWANT.LISTiC^ 


EQ)=I  AND  REQUESTOR (RES. RE 
(BES.REQ)  =  CAMMO.LON  (CCOD 


8’.c‘f»D0 


"ORDER  THE  AMMUNITION 

CREATE  A  RES.REQ  CALLED  RCODE(C,I) 

LET  COUNT  »  1 

LET  REQUESTOR  (RCODE  (C,  I)  )  *  C 
LET  RP8TR  (RCODE  (C.I))  »  RCODE (C,  I 

LET  RQTY (RCODE  (C.I) i  - * 

-  CCURR. LOAD  (CCODE  I 
LET  STATUSjfRCODE (C.I)  ,  - 
LET  RAC (RCO DEJC , I) )  *  I 
LET  R NOMEN ( RCODE (C.I) )  *  NOMEN  (I) 
LET  SPRIORITY  (RCODE  (C, I))  *  CAMMO. 
LET  TIME (RCODE (C.I)  V  *  TIME.V 

N  (C)  ♦ 


CO.B.LdAD(!:CODE  (C,I)  ) 


LON (CCODE (C,I)  ) 


LET  REQN(C) 
LET  C.NUM.R 
C.NUM. 
FILE  RCODE 

•  • 

' LOOP  1*  LOOP 

i  • 


a  »  flEQN  (C)  ♦  1 
EQN  (CCODE  (C.I) ) 
RBQN  (CCODE  (C,  if)  ‘ 
DE (C,I)  IN  CHANT 


♦  1 
LIST  (C) 


IF  COUNT  »  1 

SCHEDULE  A  UP. S4 . AMMO  (S4 . OFF  (C) ,C) 
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87  IN  UNIFORM. F  (MINTRIP  ,  M  AXTRIP  ,  TSTREAM)  MINUTES 
83  ALWAYS 

89  RETURN 

90  END 

EXPLANATION  OF  CODE 

Lines  2-4  Define  recursive  variables  use!  in  the  routine . 

Line  5  Prints  out  a  message  to  mark  the  start  of  the 
routine. 

Line  7  Starts  the  outside  loop  over  all  the  ammo  types 
carried  by  the  company.  Loop  ends  on  line  83. 

Lines  8-9  Zero  out  the  company  on-hand  ammunition  and  basic 
load  ammunition  for  the  update. 

Lines  10-15  Begin  an  inner  loop  over  all  platoons  in  the 
company  in  order  to  obtain  the  most  current  on-hand  and 
base  load  information  available  in  each  platoon.  The 
Ioof  ends  on  line  15.  Note:  the  information  obtained 
from  each  platoon  is  "current  knowledge",  which  is  what 
the  platoon  knows  it  has  on-hand,  as  opposed  to  "perfect 
knowledge",  which  is  what  the  platoon  actually  has 
on-hand. 

Lines  16-23  Check  for  a  zero  base  load  balance  in  the 

company's  aamo.  This  would  indicate  that  battle  damage 
to  company  weapons  has  negated  the  need  for  further 
requisitioning  of  that  type  of  ammo.  A  message  is 
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printed  identifying  the  round  type.  Further  requisitions 
would  not  be  made. 

Line  24-25  Compute  the  percentage  of  fill (on-hand/base 
load)  for  an  ammo  type. 

Lines  26-45  Cycle  the  percentage  over  the  five  possible  LON 
threshold  values  until  the  correct  value  is  found  and 
assigned.  Control  is  then  directed  to  lines  47-49  to 
determine  the  unit  shortage. 

Lines  47-49  Provide  an  update  of  the  total  amount  of  ammo 
the  company  is  short. 

Lines  51-55  Check  if  an  initial  ammo  request  needs  to  be 
filed.  Ammunitions  with  LON  values  equal  to  5  are 
cycled.  Additionally,  a  NO. BATTLE  check  is  made. 

NO. BATTLE  equal  to  1  indicates  that  a  simple  update  is 
required  and  no  EES. BEQs  axe  to  be  submitted. 

Lines  57-64  check  any  previous  requisitions  for  the  ammo 
type  being  reviewed.  If  the  previous  request  has  a 
priority  equal  to  the  current  LON  there  is  no  need  for  a 
new  request  to  be  filed  and  the  routine  is  cycled. 

Lines  66-80  Create  a  requisition  to  be  forwarded  to 

battalion  supply.  The  attributes  set  in  the  request 
are:  requestor  identification;  a  request  pointer;  a 
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requested  quantity;  a  request  status;  a  request  ammo 
code  pointing  to  a  particular  ammo  type;  a  request 
nomenclature;  a  request  priority;  time  submitted;  and 
total  requests  submitted  for  that  ammo  type. 

Line  81  Files  the  request  in  the  company's  want  list. 

Line  83  Closes  the  major  loop  in  the  routine  and  transfers 
control  to  Line  7  to  begin  a  loop  over  the  next  ammo 
type. 

Lines  85-88  The  variable  COUNT  keys  the  fact  that  a 

requisition  has  been  created  and  must  be  forwarded  to 
battalion.  If  appropriate,  an  UP.S4.AHHO  is  scheduled. 

I.  "ROUTINE  BATTLE" 

Routine  BATTLE  is  called  from  routine  tl.  ABBO  to  obtain 
the  most  recent  expenditure  and  damage  information.  The 
routine  generates  ammunition  expenditures  for  each  alive 
weapon  according  to  designated  rates  of  fire  and 
probabilities  of  fire.  It  also  randomly  damages  and 
destroys  vehicles  according  to  user  designated  probabilities 
of  damage. 

A  -  Bolds  the  value  of  the  weapon  system  updating  its 
situation. 
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AMM0 1 .  AP.  TOW  (A BMOR  PIERCING/TOW  ROUNDS)  . 

AMM02.  HE. DRAG (HEAT/DRAGON  ROUNDS) . 

AMM03.  AW1 .OR. MSL3  (ALTERNATE  WEAPON  1  OR  MISSILE  3). 

AMM04.  AW2. OR. ADM  (ALTERNATE  WEAPON  2  OR  AIR  DEFENSE 
MISSILE)  . 

GLOBAL  VARIABLES  l INTEGER) 

ROF (RATE  OF  FIRE)  (2-d).  Specifies  the  rates  of  fire  for  the 
six  weapons  on  board  any  weapon  system. 


RSTREAM (RESUPPLY  STREAM). 

WSTREAM (WEAPON  RANDOM  NUMBER  STREAM). 


GLOBAL  YARIABIES-IBEALL 


B. END (BATTLE  END).  Termination  time  of  daily  battle. 

B. START (BATTLE  START).  Start  time  of  daily  battle. 

POD  (2-d)  (PROBABILITY  OF  DAMAGE).  For  all  weapon  systems. 
POF (2-d) (PROBABILITY  OF  FIRE).  For  all  weapon  systems. 


TIME. 7 


LARI  (LAMBDA  1).  Holds  the  value  of  the 
for  AMMOI  from  the  POF  (PROBABILITY 
LAM2  (LAMBDA  2).  Holds  the  value  of  the 
for  AM  MO  2  from  the  POF  (PROBABILITY 


probability  of  fire 
OF  FIRE)  array, 
probability  of  fire 
OF  FIRE)  array. 
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LAM3 (LAMBDA  3).  Holds  the  value  cf  the 
for  AM HO 3  from  the  POF  (PROBABILITY 
1AM4 (LAMBDA  4).  Holds  the  value  of  the 
for  AMM04  froa  the  POF  (PROBABILITY 
LAM5 (LAMBDA  5).  Holds  the  value  of  the 
for  AM  MO  5  from  the  POF  (PROBABILITY 
LAM6 (LAMBDA  6).  Holds  the  value  of  the 
for  AMM06  froa  the  POF  (PROBABILITY 
ROUTINES  CALLED 

EXPONENTIAL. F,  MAX . F,  and  RANDOM. F  . 


probability  of 
OF  FIRE)  array 
probability  of 
OF  FIRE)  array 
probability  of 
OF  FIRE)  array 
probability  of 
OF  FIRE)  array 


fire 


fire 


fire 


fire 


TNK. ALIVE (TANK  ALIVE) .  Owned  by  the  system.  Members  are 
vehicles  still  alive  within  the  simulation. 


Sg&l 


AMM05 (AMMONITION  5).  Of  TANK. 

AMM06  (AMMUNITION  6).  Of  TANK. 

AP. TOW (ARHOR-PIERCING/TON) .  Ammunition  1  of  TANK. 

AW1. OR. MSL3 (ALTERNATE  WEAPON  1  OR  MISSILE  3).  Ammunition  3 
Of  TANK. 

AW2.0R. ADM (ALTERNATE  WEAPON  2  OB  AIR  DEFENSE  MISSILE). 
Ammunition  4  of  TANK. 
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FKILL (FIREPOWER  KILL).  Indicates  whether  a  TANK  has 


sustained  a  firepower  kill  during  the  battle. 


"0"  indicates  no 
"1"  indicates  yes 

HE. DRAG (HEAT/DRAGON  ROUNDS).  Ammunition  2  of  TANK. 


KKILL (CATASTROPHIC  KILL).  Indicates  whether  a  TANK  has 


sustained  a  catastrophic  kill  during  the  battle. 


"0"  indicates  no 
“I"  indicates  yes 

MFKILL  (MOBILITY  &  FIR EPOHSR  KILL) .  Indicates  whether  a  TANK 


has  sustained  a  mobility  and  firepower  kill  during  the 


battle. 


"O"  indicates  no 
"1"  indicates  yes 

HKILL (MOBILITY  KILL).  Indicates  whether  a  TANK  has  sustained 


a  mobility  kill  during  the  battle. 


"0"  indicates  no 
"1"  indicates  yes 
POINTER.  Machine  address  of  TANK. 


WPN.TTPE  (WEAPON  TYPE).  Of  TANK. 


PROGRAM  LISTING 


1  ROUTINE  BATTLE  (A) 

2  DEFINE  A  AS  AN  INTEGER  VARIABLE 

3  DEFINE  LAM  1,L AM2 ,LAH3, LAM4 . 

4  LANS, AND  LAM6  AS  REAL  VARIABLES 

5  •• 

6  •• CHECK  IF  BATTLE  IN  PROGRESS,  IF  NOT.  RETURN 

7  PRINT  1  LINE  WITH  E. START  AND  B. END  AS  FOLLOWS 

BST ART  ■  **.****  B . END  *  •*.**•* 

8  IF  TIMS . V  LT  B. START  OR  TIME.V  GT  B. END,  RETURN 

9  OTHERHISE 
10  " 

11  ••  ESTABLISH  BATE  OF  FIRE  FOB  EACH  AMMUNITION  FIRED. 

12  LET  LAM  1  *  HOP  (MPN.TIPE  (A)  ,  1) 
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LET  LAM2  *  HOF  (WPN.TYPE  (A)  ,  2) 

LET  LAN3  *  ROF  WPN.TYPE  (A,  ,3 
LET  LAM4  =  ROF  iWPN.TYPE  A  ,4 
LET  LAM5  *  HOF  WPN.TYPE  A  ,5 
LET  LAM6  *  ROF  WPN.TYPE  A  ,6 
ii 

"  ESTABLISH  AMMUNITION  EXPENDITURES  FOH  EACH  AMMO 
IF  RANDOM. F (RSTREAMf  LE  POF (WPN . TYPE  (A)  , 1) 


f  RANDOM.  F  (RSTREAM)  LE  POP(WPN.: 
LET  AMMOI(A)  »  MAX.FjAMMOT (A) 

-  EX PON  ENTIAL.  F (LAM 


(A)  *  MAX.FJAMM02 (A) 

-  EXPONENTIAL.  F  (LAM2*TIME.  V  ,  HSTREAM)  ,0) 

(RSTREAM)  LE  POF  (WPN .  TYPE  (A)  ,  3) 

(A)  *  MAX.F  (AMM03  (A) 

-  EXPONENTIAL.  F  (LAM3*TIME.V  ,  HSTREAM)  ,0) 


IMS* TIME.  V  ,  HSTREAM)  ,0) 


k M 6+ TIME.  V  ,  HSTREAM)  ,0) 


-  EXPONENTIAL.  F  (LAM  1*TIME.  V  ,  HSTREAM)  ,  0) 

ALWAYS 

IF  RANDOM.  F  (RSTREAM)  LE  POF (WPN  .  TYPE  (A)  ,  2) 

LET  ANM02 (A)  *  M AX . F JAMM02 (A) 

-  EXPONENTIAL.  F  (LAM2*TIME.  V  ,  HSTREAM)  ,  0) 

ALWAYS 

IF  RANDOM.  F(RSTREAM)  LE  POF (WPN .  TYPE  (A)  ,  3) 

LET  AMH03 (A)  *  MAX .F (AMM03  (A) 

-  EXPONENTIAL.  F  (LAM3*TIME.V  ,  HSTREAM)  ,0) 

ALWAYS 

IF  RANDOM.  F  (RSTREAM)  LE  POF  (WPN.  TYPE  (A)  ,  4) 

LET  AMM04 (A)  =  MAX.F  (AMM04 (A) 

-  EXPONENTIAL.  F (LAM4*TIME. V , HSTREAM)  ,0) 

ALWAYS 

IF  RANDOM.  F  (RSTREAM)  LE  POF  (WPN  .  TYPE  (A)  ,  5) 

LET  AHH05 (A)  ■  MAX.F JAMM05 (A) 

-  EXPONENTIAL.  F  (LAM 5* TIME.  V  ,  HSTREAM)  ,  0) 

ALWAYS 

IF  RANDOM.  F  (RSTREAM)  LE  POF  (WPN .  TYPE  (A)  ,6) 

LET  ANH06 (A)  *  MAX.F  (AMM06 (A) 

-  EXPON  ENTIAL.  F  (LAM6*TIHE.  V  ,  HSTREAM)  ,0) 

ALWAYS 
1 1 

"DETERMINE  IF  DAMAGES  HATE  BEEN  SUSTAINED 
IF  RANDOM.  F  (RSTREAM)  LE  POD  (HPN .  TYPE  (A)  ,  1 ) 

LET  MKILLjA)  *  1 
PRINT  1  LINES  THUS 

BATTLE  DAMAGE  SUSTAINED 
LIST  POINTER  (A)  ,  MKILL  (A) 

ALWAYS 

IF  RANDOM.  F  (RSTREAM)  LE  POD  (WPN.  TYPE  (A)  ,  2) 

LET  FKILL(A)  =  1 
PRINT  1  LINES  THUS 

BATTLE  DAMAGE  SUSTAINED 
LIST  POINTER  (A)  ,  FRILL  (A) 

ALWAYS 

IF  RANDOM.  F  (RSTREAM)  LE  POD  (WPN .  TYPE  (A)  r  3) 

LET  HFKILL(A)  *  1 
PRINT  1  LINE  THUS 

BATTLE  DAMAGE  SUSTAINED 
LIST  POINTER  (A).  M  FRILL  (A) 

REMOTE  A  FROM  TNR. ALIVE 
ALWAYS 

IF  RANDOM. F (RSTREAM)  LE  POD (WPN.TYPE  (A) ,4) 

LET  RKILLJaT  »  1 
PRINT  1  LINE  THUS 

BATTLE  DAMAGE  SUSTAINED 
LIST  POINTER  (A), KRILL  (A) 

REMOVE  A  FROM  TNR. ALIVE 
ALWAYS 
RETURN 
END 


Lines  2-4  Define  recursive  variables  used  in  the  routine. 
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Lines  6-9  Check  if  a  battle  is  currently  in  progress,  if 
not  it  causes  the  routine  to  return  without  action. 

Lines  11-17  Assign  a  rate  of  fire  by  weapon  and  ammunition 
type  for  the  six  ammo  types  carried  by  the  weapon 
updating.  Rates  of  fire  are  obtained  from  a  rate  of  fire 
array  input  by  the  user. 

Lines  19-43  Establish  ammo  expenditures  for  each  of  the  six 
ammo  types  carried  by  a  weapon  system.  Use  of  the  weapon 
during  the  time  period  is  established  by  comparing  a 
random  number  to  a  probability  of  fire  for  the  weapon 
system.  Expenditure  of  ammo  is  then  computed  through  the 
use  of  an  exponential  function  using  the  weapon's  rate 
of  fire  as  lambda. 

Lines  45-71  Determine  if  battle  damage  has  been  sustained 
during  the  time  period.  Evaluation  is  made  by  comparing 
a  random  number  against  the  various  types  of  kill 
possible. 


J.  "ROOTIBB  OP. DATE" 

Soutine  OP. DATS  is  called  from  event  8. OP. DATS  and  is 
used  to  print  a  battle  summary  listing  weapon  and  unit 
assets,  as  well  as  supply  status. 

5i2£Ai_IAHMiE5_limS££L 
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CCL. 7. ITEM  (CO HP  ANY  CLASS  V  ITEM). 

COMPANY. COMMANDER 
CONVOY 

CNOM  (COMPANY  NUMBER).  Specifies  the  number  of 
COMPANY. COMMANDERS  created. 

PCL.V.  ITEM  (PLATOON  CLASS  V  ITEM). 

PLATOON. LEADER 
PNUH (PLATOON  NUMBER) . 

RES.  REQ.  (RESUPPLY  REQUEST). 

SCL.V.  ITEM.  (SUPPLY  CLASS  V  ITEM). 

SNUN (NUMBER  OF  SUPPLY  OFFICERS). 

SUPPLY. OFFICER 
T.CGO (TRUCK  CARGO). 

TANK 

EgRBABBBT..  AlXBlfifllSS 

TIME.? 

5ggM2UM-XM£A5It£2 

I,  J,  K  -  Loop  indicies. 

2512. 

CARGO 

CO. AMMO (COMPANY  AMMUNITION).  Owned  by  a  COMP  ANY. COMMANDER . 
Meebers  are  the  unit*s  CCL. 7. ITEMS (COMPANY  CLASS  V 
ITEMS)  . 
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CHANT.  LIST  (COMPANY  WANT  LIST). 

PLAT. UNIT (PLATOON  UNIT).  Owned  by  a  PLATOON. LEADER.  Members 
are  the  unit's  combat  vehicles (TANKS)  . 

PLT. AMMO  (PLATOON  AMMUNITION)  .  Owned  by  a  PLATOON. LEADER. 
Members  are  the  unit's  PCL.V. ITEMS (PLATOON  CLASS  V 
ITEMS)  . 

S.AMMO (SUPPLY  AMMUNITION).  Owned  by  a  SUPPLY . OFFICES. 

Members  are  the  unit's  SCL. 7. ITEMS (SUPPLY  CLASS  V 
ITEMS)  . 

S. UNIT (SUPPLY  UNIT).  Owned  by  a  SUPPLY. OFFICES.  Members  are 
the  unit's  supply  vehicles (TANKS)  . 

SCONVOY  (SUPPLY  CONVOY) . 

SHEQN. LIST (SUPPLY  REQUISITION  LIST). 

SNANT. LIST  (SUPPLY  WANT  LIST).  Owned  by  a  SUPPLY. OFFICES. 

Members  are  RES. HEQs (RESUPPLY  REQUESTS)  from  the  combat 
units. 


i 

t 
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6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 


32 

33 


FOR  J  *  1  TO  CNDM,  DO 

LIST  ATTRIBUTES  OF  EACH  CCL.V.ITBM  IH  CO.AMMOfJ 
LIST  ATTRIBUTES  OF  EACH  RES. REQ  IN  CHANT. LIST (J 
LOOP 

t  • 

LIST  ATTRIBUTES  OF  EVERY  PLATOON. LEADER 
FOR  I  *  1  TO  PNOM,  DO 

LIST  ATTRIBUTES  OF  EACH  PCL.V.ITEM  IN  PLT.AMMO(I) 
LIST  ATTRIBUTES  OF  EACH  TANK  IN  PLAT. UNIT  (I) 

LOOP 

« i 

LIST  ATTRIBUTES  OF  EVERY  SUPPLY. OFFICER 
FOR  K  *  1  TO  SNUM,  DO 

LIST  ATTRIBUTES  OF  EACH  SCL.V.ITEM  IN  S 
LIST  ATTRIBUTES  OF  EACH  RES. REQ  IN  SHANT.LIST 
LIST  ATTRIBUTES  OF  EACH  RES. REQ  IN  SREQN. LIST (K 
LIST  ATTRIBUTES  OF  EACH  CONVOY  IN  SCONVOY(K) 
LIST  ATTRIBUTES  OF  EACH  TANK  IN  S.UNIT(K) 

LOOP 
<  • 

FOR  EACH  TANK  IN  TNK. ALIVE 
WITH  SYS. TYPE (TANK)  EQ  7,  DO 

LIST  ATTRIBUTES  OF  EACH  T.CGO  IN  CARGO  (TANK) 
LOOP 

• « 

PRINT  2  LINES  HITH  TIME.V  AS  FOLLOHS 

•  f 

ROUTINE  UP. DATE  ENDED  AT  •*.***• 

RETURN 
END 


AMMOiKj^ 


EXPLANATION  OF  CODE 

Line  2  Defines  recursive  variables  for  the  routine. 


Line  3  Prints  a  message  marking  the  start  of  the  routine 
Lines  5-9  Mark  a  loop  over  the  attributes  and  sets 


belonging  to  each  company  commander. 

Line  5  Lists  attributes  of  each  company  commander. 

Line  7  Lists  attributes  of  each  class  V  item  the  company 
commnander  owns. 


Line  8  Lists  attributes  of  each  resupply  reguest  the 
company  commander  has  outstanding. 

Lines  11-15  Hark  a  loop  over  the  attributes  and  sets 
belonging  to  each  platoon  leader. 


Line  11  Lists  attributes  of  each  PLATOON. LEADER. 
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Line  13  Lists  the  the  attributes  of  each  class  V  itea  the 


platoon  leader  owns. 

Line  14  Lists  the  attributes  of  each  weapon  system  of  the 
unit. 

Lines  17-24  Marie  a  loop  over  the  attributes  and  sets 
belonging  to  each  supply  officer. 

Line  17  Lists  the  attributes  of  each  supply  officer 

Line  19  Lists  the  attributes  of  each  class  7  itea 

Line  20  Lists  the  attributes  of  outstanding  requests  from 

supported  companies. 

Line  21  Lists  the  attributes  of  outstanding  requests  sent 
to  the  ATP/ ASP. 

Line  22  Lists  the  attributes  of  each  convoy  the  supply  unit 
owns. 

Line  23  Lists  the  attributes  of  all  supply  vehicles  in  the 
unit. 

Linas  26-29  Hark  a  loop  over  all  resupply  vehicles,  listing 
the  attributes  of  all  supply  cargo  carried. 

K.  "ROUTIHE  PILE.  UP.  DATE" 

This  routine  is  called  from  event  U P.S4.AMMO.  It  is 

used  to  update  the  S-4's  out  standing  request  list  by  filing 
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new  requests  by  priority  and  eliminating  duplicate  older 
requests  of  lesser  priority. 


ARGUMENT 

A  -  Points  to  supply  officer  updating. 


COM.  Points  to  coapany  currently  updating. 

GLOBAL  V ABIABLE  (INTEGER) 

SCODE (SUPPLY  CODE)  (2-d).  HOLD'S  POINTER  FOR  SCL.V. ITEMS. 


N. SWANT. LIST (NUMBER  IN  SUPPLY  WANT). 


NEW. REQ  (NEB  REQUISITION). 

OLD.  RE  Q  (OLD  REQUISITION). 

ROUTINES  CALLED 
FILE. UPDATE 

SETS  USED 

CWANT. LIST (COMPANY  WANT  LIST). 
SWANT.  LIST  (SUPPLY  WANT  LIST). 


XlB£OBi£X_AH£I£2m.iX£2££g&L 

DEMAND,  for  SCL . 7. ITEM. 

M.C.CGO. LIST (MEMBER  CONVOY  CARGO  LIST).  System  generated 

variable  indicating  whether  or  not  a  resupply  request  is 
on  a  convoy  cargo  list. 
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SAC (RESUPPLY  AMMUNITION  CODE).  Attribute  of  an  SCI. V. ITEM 
which  points  to  a  specific  aaao  type  carried  by  the 
supply  unit. 

REQUESTOR.  Attribute  of  a  RES.REQ  pointing  to  the  requesting 
unit . 

RQTY (RESUPPLY  QUANTITY).  Attribute  of  a  RES.REQ  holding  the 
total  quantity  requested  by  a  unit. 

SPRIORITY (SUPPLY  PRIORITY).  Attribute  of  a  RES.REQ 

specifying  the  urgency  of  need  for  the  aaao  request. 

TEMPORARY  ATTRIBUTE  (ALPHA) 

RNOMEN (RESUPPLY  NOMENCLATURE).  Attribute  of  a  RES.REQ 
specifying  the  requested  aaao’s  noaenclature. 

TEMPORARY  ENTITY 

RES.REQ (RESUPPLY  REQUEST). 

SCL. V. ITEM  (SUPPLY  CLASS  V  ITEM).  Holds  inforaation  for  a 
supply  unit  about  a  particular  aaao  type  used  by  the 
unit.  Belongs  to  the  set  S.AHMO. 

PERMANENT- ATTRIBUTE. iPOUBLS) 

TIME. V .  Siaulation  tiae. 

lEflaiifl.  asms 

1  ROUTINE  FILE.  UPDATE  (A,  COM) 

2  DEFINE  A.COH.OLD. REQ.NEW.REQ  AS  INTEGER  VARIABLES 

3  •«  FILE  THE  REQUEST  CURRENTLY  BEING  RECEIVED 

4  *•  AND  CAPTURE  DEMAND  DATA 

5  PRINT  1  LINE  «ITH  TIHE.V  THUS 

ROUTINE  FILE. UPDATE  CALLED  AT  TIHE.V  =  **.**** 
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»0-AU»  322  NAVAL  FOSTOAAOUATC  SCHOOL  MONTCMT  CA 

A  HI2H  AESOLUTION  AMMUNITION  NCSUONLV  MOOCL.(U) 
MAN  02  A  J  OUC HA*  T  J  NCMANN 


UNCLASSIFIED 


8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 
23 

2! 

26 

27 

28 
29 
31 


IF  NEW. REQ  IS  MOT  IN  SOME  SWAN T. LIST 
LET  DEMAND  (SCODE  (A ,RAC  (NEK.  REQ)  )  )  - 
DEMAND (SCODE (A, RAC  (NEW . SEQ) )}♦  RQTY (NEW. REQ) 
ALWAYS 

FOR  ALL  OLD. REQ  IN  SHANT.LIST  (A) 

D .  REQ)  s  RNOMEN 
ID.  REQ)  *  0 

‘  ^  DO 


WITH  RNOMEN (OL 

AND  M . C. CSO. LIST (0 _ 

AND  REQUESTOR (OLD. REQ)  »  RE 
IF  SPRIORITY  (OLD. REQ’  ““ 

LET  DEMANDjSCODEjA _  _ 

DEMAND (SCODEjA.RSC  (OLD.REQ)) ) 

♦  RQTY (NEW. REQ)  -  HQTY  (OLD .REQ) 
REMOVE  OLD.REQ  FROM  SHANT.LIST! 
REMOVE  OLD.REQ  FROM  CHANT. LIST 
DESTROY  RES. REQ  CALLED  OLD.REQ 
ALWAYS 
LOOP 

IF  NEW. REQ  IS  NOT  IN  SOME  SHANT.LIST, 
PILE  NEW. REQ  IN  SHANT.LIST (A) 

ALWAYS 

LOOP 

RETURN 

END 


In^H. REQ) 

)  »'  REQUESTOR  (NEW. REQ)  , DO 
Q)  NE  SPRIORITY  (NEH. REQ)  , 
|,RAC(N|H^REQ)))  * 

fcf)M) 


EXPLANATION  OF  CODE 

Line  2  Defines  the  recursive  variables  used  in  the  routine. 

Line  5  Prints  a  message  marking  the  beginning  of  the  event. 

Lines  6-7  Begin  the  major  outer  loop  for  the  routine  by 

looping  over  all  outstanding  requests  that  have  not  been 
loaded  on  a  resupply  truck.  Loop  ends  on  line  28. 

Lines  8-11  Determine  if  the  request  has  been  filed 

previously  with  the  S-4.  If  not  it  is  treated  as  new  and 
its  full  demand  data  is  captured. 

Lines  12-25  Begin  an  inner  loop  which  determines  if  a 


similar  request  for  the  type  of  ammo  in  the  outer  loop 
has  been  filed  previously  with  the  S-4.  If  so,  a 
comparison  is  made  between  request  priority  values.  If 


the  values  are  the  same,  this  indicates  that  the  new 


request  has  been  filed  previously  and  no  further  action 
is  necessary.  If  the  priorities  are  different,  this 
indicates  that  the  unit  is  increasing  its  urgency  of 
need  for  the  aaao.  The  new  request  is  filed  and  the  old 
one  is  destroyed.  The  difference  between  the  new  and 
old  values  is  added  to  the  desand.  Loop  ends  on  line 
24. 

Line  24  Closes  the  inner  loop  for  the  routine.  Control  is 
transferred  back  to  line  12  to  continue  cosparing 
requests  or  out  to  the  next  new  request. 

Lines  25-27  Pile  all  genuinely  new  requests  in  the  S-4*s 
Bant  list. 

Line  28  Closes  the  sain  routine  loop  begun  on  line  8. 

Control  is  transferred  back  to  the  next  request  or  out. 

L.  "ROUTINE  LORD. THE. TRUCKS" 

This  routine  is  called  froa  event  UP.S4. RHHO.  It  is 
used  to  load  supply  cargo  onto  individual  trucks.  In 
execution,  the  event  checks  the  nuaber  of  tracks  allocated 
to  carry  a  specific  supply  request  and  loads  the  nuaber  of 
trucks  specified  subject  to  the  weight  and  cube  liaitations 
of  the  truck. 

ARGUMENT  (INTEGER) 

R  -  Pointer  value  to  the  S-4  officer. 
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CON. ID (CONYOY  ID).  Holds  the  pointer  value  of  the  convoy 
currently  being  filled. 

N.  RNDS  (NUMBER  OF  ROUNDS). 

SR (RESUPPLY  REQUEST).  Holds  the  pointer  of  the  resupply 
request  being  currently  filled. 

ARGUMENT  (REAL) 

CO . REQ (CUBE  REQUIRED).  Holds  the  total  cube  that  is  required 
in  order  to  ship  a  resupply  request. 

WT. REQ (HEIGHT  REQUIRED).  Holds  the  total  weight  that  is 
required  in  order  to  ship  a  resupply  reguest. 

RES. REQ  (RESUPPLY  REQUEST) . 

SCODE (SUPPLY  CODE)  . 

TANK 

£5£mii5^Mim£5-iima£aL 

RC.TEMP (ROUND/COBE  TEMPORARY).  Holds  the  coaputat ional  value 
of  the  nuaber  of  rounds  that  lay  be  loaded  on  a  truck 
due  to  cube  restrictions. 

RNDS (ROUNDS) .  Holds  the  nuaber  of  rounds  being  released  to 
fill  a  request. 

RW.TEMP (ROUND/HEIGHT  TEMPORARY).  Holds  the  coaputational 
value  of  the  nuaber  of  rounds  that  aay  be  loaded  on  a 
truck  due  to  weight  restrictions. 
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T.  COUNT  (TRUCK  COUNT).  Holds  the  value  of  the  nuaber  of 


t 


( 


trucks  already  loaded  for  a  particular  resupply  request. 
RECURSIVE  VARIABLE _ (BEAL) 

PCT  (PERCENT)  . 

ROUTINES 

LOAD. THE. TRUCK,  MIN.F,  TRUNC.F 
SETS  USED 

CARGO.  Contains  a  listing  of  the  T.CGO  loaded  on  a 
particular  truck. 

ELEMENTS.  Set  of  trucks  owned  by  a  CONVOY. 

S. UNIT (SUPPLY  UNIT).  Contains  the  unit's  supply 
vehicles  (TANKS)  . 

TEMPORARY  ATTRIBUTES  (ALPHA) 

RNOMEN (RESUPPLY  NOMENCLATURE).  Attribute  of  an  SCL.V.ITEM 
containing  the  naae  of  the  particular  aano  type. 

TNOMEN (TRUCK  NOMENCLATURE).  Contains  the  naae  of  a 


particular  aamo  type. 


FKILL (FIREPOWER  KILL). 

KKILL  (CATASTROPHIC  KILL). 

H. ELEMENTS.  Specifies  aeabership  in  a  CONVOY. 
HFKILL (MOBILITY  AND  FIREPOWER  KILL). 

MKILL (MOBILITY  KILL). 
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N. CARGO  (NUMBER  IN  CARGO)  .  Indicates  the  total  number  of 
T.CGO  items  loaded  on  a  particular  truck. 

N. ELEMENTS  (NUMBER  OF  ELEMENTS).  In  a  convoy. 

N.T. ALLOC (NUMBER  OF  TRUCKS  ALLOCATED).  Contains  the  number 
of  trucks  to  be  allocated  to  move  the  rounds  released 
for  a  resupply  request. 

ONHAND.  Holds  the  on-hand  balance  for  rounds  of  a  particular 
type  at  the  resupply  point. 

POINTEH.  Of  a  TANK. 

RAC (R2S0PPLY  AMMUNITION  CODE).  Attribute  of  an  SCL.V.ITEM 
which  points  to  a  specific  ammo  type  carried  by  the 
supply  unit. 

RDS.PKG  (ROUNDS  PACKAGE).  Attribute  of  a  SCL.V.ITEM 

specifying  the  number  of  rounds  on  an  ammo  pallet. 

RFILL (RESUPPLY  FILL).  Attribute  of  a  RES.REQ  specifying  the 
amount  of  ammunition  released  to  fill  a  request. 

RQTY (RESUPPLY  QUANTITY).  Attribute  of  a  RES.REQ  holding  the 
total  quantity  requested  by  a  unit. 

RRPNTR (RESUPPLY  REQUEST  POINTER) . 

SPACE.  Attribute  of  a  CONVOY  holding  the  amount  of  loading 
space  available  on  trucks  in  the  convoy. 


TCU  (TRUCK  CUBS)  .  The  cube  that  a  truck  has  available  to  be 
filled. 

TPNTR (TRUCK  POINTER). 

TQTY (TRUCK  QUANTITY) .  Holds  the  nuaber  of  rounds  within  a 
T.CGO  that  are  loaded  on  a  truck. 

TRAC (TRUCK  AMMUNITION  COOS).  Of  a  T.CGO  itea. 

TNT  (TRUCK  HEIGHT).  The  weight  that  a  truck  has  available  to 
be  filled. 


CU.  PKG  (CUBE  PACKAGE)  Attribute  Of  a  SCL.  7.  ITEM  specifying 
the  cube  of  an  aaaunition  pallet. 

HT. PKG  (HEIGHT  PACKAGE).  Attribute  of  a  SCL. V. ITEM  specifying 
the  weight  of  a  pallet  of  the  aaao  being  considered. 


XBBBQBABI-Smil 

T.CGO.  Supplies  carried  on  a  resupply  vehicle  (TANK)  . 
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6 
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8 
9 

10 

11 

12 

13 

14 

15 

H 

18 

19 


ROUTINE  LOAD. THE. TRUCKS 
(A,R8,HT.REQ.CU.RSQlN.  RNDS.CON.ID) 

DEPINE  A.PR.N . BHDS, CON . ID.  T. COUNT, RR .TEMP, 

RC. TEMP, ENDS  IS  INTEGER  VARIABLES 
DEFINE  HT. REQ, CO. REQ,PCT  AS  REAL  VARIABLES 
PRINT  1  LINE  THUS 

ROUTINE  LOAD  THE  TRUCKS  CALLED 
LET  T. COUNT  ■  0 
FOR  EVERY  TANK  IN  S.  UNIT  (A) 

ttWMM  li  t  wm  k  Ml**  MIA  "Q* 

FKILL  (TANK)  EQ  0 
„  _  0  KRILL (TANK)  EQ 

' *  LOOP  CHECK 

LET  T. COUNT  ■  T. COUNT  el 

IF  T. COUNT  GT  N.  T.  ALLOC  (RES.  REQ)  OS  HT.REQ  L£  0 
OR  CU . REQ  LE  0  OR  N . HMDS  LE  0 
LEAVE 
OTHBBRISE 

"  CHECK  IF  ITEMS  EXCEED  THE  TRUCK'S  CAPACITY 
"  IF  SO,  ADJUST 


rUK  JSVJSKX  TASK  J.  H  S.UHJ.T 

HITH  M. ELEMENTS (TANK)  EQ 
AND  NKXLL(TANK)  EQ  0  AND 
AND  MFRILLJTANK)  EQ  0  AN 


9,  DO 
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I 


( 


20 

21 

22 

23 

is 

27 

28 

29 

30 

31 

32 

33 

35 

36 

37 

11 

40 

41 

42 

43 

44 

45 

46 

47 

48 

11 

11 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 


IP  HT.REQ  GT  THT  (TANK)  06  CU.SEQ  GT  TCU  (TANK) 
LET  RH.TEMP  *  THT (TANK) 

/HT.PKG(SCODE (A, RAC  (RES. RE 
*  RDS . PKG (SCODE  (A , RAC (RES 
LET  RC.TEMP  =  TCO (TANK) 

/CO. PKG (SCODE (A, RAC (RES. 

>4  RDS .  PKG  (SCODE  (A.  RAC  (RES.  R 
LET  RNDS  =  MIN  .F  (RW . TEMP.RC. TEMP) 

LET  N. RNDS  *  N . RNDS  -  RNDS 
ELSE 

LET  RNDS  =  N. RNDS 
LET  SPACE  (CON. ID)  =  1 
ALW ATS 

CREATE  A  T.CGO 

LET  TPNTR  (T.CGO)  =  POINTER  (TANK) 

LET  RRPNTH (T.CGO)  =  RES. REG 
LET  TNOMEN (T.CGO)  *  R NOMEN (RES . REQ) 

LET  TRAC  (T.CGO)  *  RAC  (RES. REQ) 


LET  TQTY  (T.CGO)  «  RNDS 
FILE  T.CGO  IN  CARGO (TANK) 

••REDUCE  THE  OUTSTANDING  QUANTITY  ON  THE  RES. REQ 
LET  N. RNDS  =  N .  RNDS  >  RNDS 
LET  RFILL (RES. REQ)  *  RFILL (RES .REQ)  ♦  RNDS 
LET  RQTY  (HES.BEQ)  *  RQTY (RES. REQ)  -  RNDS 
••REDOCE  THE  ON-HAND  BALANCE  OF  SOPPLY  STOCKS 
LET  ONHAND (SCODE (A .RAC (RES . REQ) ) ) 

ONHAND  (SCODE^A, fiic J 


••REDOCE  THE  HEIGHT  AND  CUBE  REQ* D  FOR 


LET  HT.REQ”  TRUNC. ? (HT .REQ  -  RNDS 


(RES. REQ) ))  -  RNDS 
rn  por  THE 


RES. REQ 


(A, RAC (RES. RE 


LET  CO.  REQa 


8tii 


) 


HT . P KG  (SCOD-  _ _ _ _ 

/RDS. PKG  (SCODE (A, RAC (RES. RE 
TRUNC. F(C0. REQ  -  ENDS 
*  CO. PKG  (SCODfi  (A, RAC  (RES. REQ) )  ) 
/RDS. PKG (SCODE jA,RACjRES.fiEQn  J) 


••REDOCE  THE  HEIGHT  AND  COSE  A  FAIL  ON  Tfffc  t&UCK 
LET  THT  (TANK)  »  TRONC.  F (THT  (TANK)  -  RNDS 
*  HT. PKG (SCODE (A r RAC (RES. BE 
/RDS. PKG  (SCODE  (A .RAC (RES. BE 
LET  TCO  (TANK)  =  TRONC.  F  (TCO  (TANK)  -  RND 

•  HT. PKG (SCODE (A, RAC (RES. REQ)  )  ) 
RDS. PKG  (SCODE JA, RAC (RES. REQ)  )  ) ) 


FILE 

LOOP 

RETURN 

END 


TANK 


IN  £ 


LEHENTS (CON . ID) 


Lines  3-5  Define  recursive  variables  used  in  the  routine. 

Line  6  prints  a  sassage  indicating  that  the  routine  has 
been  called. 

Lines  8-11  Begin  the  sajor  loop  for  the  routine  to  assign 
the  resupply  aission  to  vehicles  in  the  supply  unit  that 
have  not  previously  sustained  damage  or  been  assigned  to 
a  convoy.  Loop  ends  on  line  62. 
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Lines  12-17  Check  the  loop  for  completion  through  the 
assignment  of  all  trucks  allocated  to  the  mission,  or 
through  the  completion  of  the  loading  process. 

Lines  18-32  Check  if  the  request  exceeds  the  carrying 
capacity  of  the  truck  being  loaded.  If  so,  the  amount 
being  loaded  is  adjusted  to  the  maximum  load  for  that 
truck. 

Line  33  Creates  a  TRUCK. CARGO  to  hold  information  as  to  the 
type  and  quantity  of  ammo  to  be  loaded  on  a  truck. 

Line  34  Captures  the  pointer  value  of  the  truck  the  cargo 
is  loaded  on. 

Lina  35  Captures  the  pointer  value  of  the  resupply  request 
being  filled. 

Line  36  Captures  the  nomenclature  of  the  request  being 
filled. 

Line  37  Captures  the  ammunition  code  of  the  request  being 
filled 

Line  38  Captures  the  quantity  being  loaded  on  the  truck. 

Line  39  Piles  the  cargo  on  the  last  truck  in  the  convoy. 

Line  41  Reduces  the  number  of  rounds  yet  to  be  filled  for 
the  request 
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Line  42  Adds  the  quantity  released  to  the  fill  attribute  of 
the  request. 

Line  43  Reduces  the  required  quantity  for  the  resupply 
request. 

Lines  44-46  Reduce  the  on-hand  stocks  for  the  aasto  type  at 
the  supply  point. 

Lines  47-53  Reduce  the  weight  and  cube  required  to  fill  the 
request. 

Lines  54-60  Reduce  the  weight  and  cube  available  on  the 
truck  to  fill  requests. 

Line  61  Files  the  truck  in  the  active  convoy. 

Line  62  Closes  the  najor  routine  loop  begun  on  line  8. 

Control  is  either  transferred  back  to  fill  another  truck 
with  the  sane  cargo  or  transferred  out. 

!!.  "ROUTINE  NT.AND.CU" 

This  routine  is  called  by  event  UP. S4. ANNO  and  is  used 
to  compute  the  total  weight  and  cube  capacity  present  at 
battalion  which  can  be  used  to  carry  supplies. 

A  -  Points  to  supply  officer  updating. 


3 
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CO  (COBS)  .  Holds  the  maximum  cube  that  may  be  loaded  on  a 
resupply  vehicle. 

CO.  AVAIL  {COBB  AVAILABLE).  Holds  the  total  cube  capacity  that 
is  available  within  the  supply  unit  for  the  shipment,  of 
supplies. 

TRKS. AVAIL  (TROCKS. AVAILABLE)  .  Holds  the  total  number  of 

trucks  available  for  assignment  to  a  resupply  mission  at 
any  time. 

WT  (HEIGHT)  .  Holds  the  maximum  weight  that  may  be  loaded  on  a 
resupply  vehicle. 

HT.  AVAIL  (HEIGHT  AVAILABLE).  Holds  the  total  weight  capacity 
that  is  available  within  the  supply  unit  for  the 
shipment  of  supplies. 


TANK 


S£1 

S.UNIT (SOPPLY  ONIT)  .  Contains  the  unit's  supply 
vehicles (TANKS) . 


.nms££i 


FKILL (PIREPOHER  KILL). 

KKILL  (CATASTROPHIC  KILL). 

H. ELEMENTS .  Specifies  membership  in  a  CONVOY. 
NAX.COBE (BAXIHOH  COBS). 
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MAX. HT (MAXIMUM  HEIGHT). 

MFKILL (MOBILITY  AND  FIREPOWER  KILL). 

SKILL  (MOBILITY  KILL). 

HT  (HEIGHT)  .  Holds  the  maximum  weight  that  may  be  loaded  on  a 
resupply  vehicle. 

ROUTINE  CALLED 
HT. AND. CUBE 


PROGRAM  LISTING 


1  ROUTINE  WT.ANE.CUBE  GIVEN  A 

2  X IELDING  HT. AVAIL, CU. AVAIL, TRKS. AVAIL, HT, CO 

3  DEFINE  HT. AVAIL, CU. AVAIL, HT,CU  AS  REAL  VARIABLES 

4  DEFINE  TRKS.  AVAIL,  A  AS  INTEGER  VARIABLES 

5  PRINT  1  LINE  THUS 

ROUTINE  HT. AND. CUBE  CALLED 

•  t 

••  DETERMINE  THE  HT. AND  CUBE  AVAIL  FOR  SHIPPING 
FOR  EVERY  TANK  IN  S.  UNIT  (A) 

HITH  M. ELEMENTS (TANK)  EQ  0 


6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 
19 


AND  MKILL  (TANK)  EO  0  AND  FKILL  (TANK)  EQ  0 
AND  HFKILL  (TANK)  EQ  0  AND  KKILL (TANK)  EQ  0, 
LET  HT. AVAIL  *  HT. AVAIL  ♦  MAX. HT (TANK) 

LET  CO. AVAIL  *  CU. AVAIL  ♦  MAX. CUBE  (TANK) 
LET  TRKS. AVAIL  =  TRKS. AVAIL  ♦  1 
LET  HT  *  MAX. HT (TANK) 

LET  CU  *  MAX. CUBE (TANK) 

LOOP 

RETURN 

END 


DO 


Lines  3-4  Define  recursive  variables  used  in  the  routine, 
Line  5  Prints  a  message  indicating  that  the  routine  has 
been  called. 


Lines  8-17  Begin  the  major  loop  for  the  routine,  looping 
over  all  available  cargo  carriers,  sussing  the  total 
weight  and  cube  available  for  shipment,  determining  a 


\ 
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tonal  number  of  trucks  available,  and  determining  the 
max  weigh-:  and  max  cube  available  on  any  one  truck. 

N.  "SOUTINE  PRI. RESUPPLY" 

This  routine  is  called  by  event  UP. S4. AMMO  and  is  used 
to  determine  an  optimum  fill  for  priority  1  and  2 
requisitions.  In  execution,  the  routine  seeks  to  fill  all 
priority  2  requesitions  to  a  minimum  percentage  of  fill  for 
all  requests  by:  first,  setting  multipliers  to  reduce 
priority  2  fill;  second,  re-evaluating  the  overall  fill  of 
priority  2  requests;  and  third,  if  necessary,  reducing  fill 
on  priority  1  requests  to  open  more  space  for  priority  2 
requests. 

ARGUMENT  (INTEGER) 

A  -  Points  to  the  S-4  currently  updating. 

LON  1 .  Variable  which  indicates  whether  Level  of  Need  1 

requests  are  currently  filed  with  the  supply  officer. 

LON 2.  Variable  which  indicates  whether  Level  of  Need  2 
requests  are  currently  filed  with  the  supply  officer. 
ARGUMENT  fREAL) 

CU.  AVAIL  (CUBE  AVAILABLE).  Holds  the  total  cube  capacity  that 
is  available  within  the  supply  unit  for  the  shipment  of 
supplies. 
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M0L1 (MULTIPLIES  1).  Holds  the  multiplier  for  LON  1  requests 
which  is  used  to  reduce  the  fill  on  such  requests. 

21UL2  (HOLTIPLIER  2).  Holds  the  multiplier  for  LON  2  requests 
which  is  used  to  reduce  the  fill  on  such  requests. 

«T.  AVAIL  (HEIGHT  AV  AIL  ABLE)  .  Holds  the  total  weight  capacity 
that  is  available  within  the  supply  unit  for  the 
shipment  of  supplies. 

GLOBAL  VARIABLES  /INTEGER) 

RES.REQ (RESUPPLY  REQUEST)  . 

SCODE (SUPPLY  CODE). 

C.L1PCT  (CRITICAL  LON1  PERCENTAGE).  Holds  the  maximum 

percentage  that  LON1  requisitions  may  be  reduced  to  in 
order  to  release  space  on  a  convoy  for  other  critical 
LON  1  and  LON2  requests. 

C.L2CU  (CRITICAL  LON2  CUBE).  Holds  the  maximum  percent  of 
cube  that  L0N2  requisitions  may  be  cut  to  in  order  to 
release  space  on  a  convoy  for  other  critical  LON1  and 
LON2  requisitions. 

C.L2WT (CRITICAL  L0N2  HEIGHT) .  Holds  the  maximum  percent  of 
weight  that  LON2  requisitions  may  be  cut  to  in  order  to 
release  space  on  a  convoy  for  other  critical  LON1  and 
LON 2  requisitions. 
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CO. SHIP (CUBE  OP  SHIPMENT) -  Combined  total  cube  of  current 
LONI  and  L0N2  requests. 

Cl.  Holds  the  total  cube  of  current  L0N1  requests. 

C1PCT.  Percent  of  LONI  requests  which  can  be  filled  if  all 
L0N2  requests  are  filled  to  a  minimum  based  on  cube. 

C2.  Holds  the  total  cube  of  current  L0N2  requests. 

C2PCT.  Percent  of  L0N2  requests  which  can  be  filled  if  all 
LON 1  requests  are  filled  based  on  cube. 

NT. SHIP  (HEIGHT  OF  SHIPHENT).  Combined  total  weight  of 
current  L0N1  and  LON2  requests. 

HI.  Holds  the  total  weight  of  current  LONI  requests. 

H1PCT.  Percent  of  LONI  requests  which  can  be  filled  if  all 
LON 2  requests  are  filled  to  a  ainiaua  based  on  weight. 

H2.  Holds  the  total  weight  of  current  L0N2  requests. 

W2PCT.  Percent  of  L0N2  requests  which  can  be  filled  if  all 
L0N1  requests  are  filled  based  on  weight. 

ROOTINBS 

MAX.P,  MIN .  P,  PHI. RESUPPLY 

SS2 

SWA  NT.  LIST  (SUPPLY  WANT  LIST). 

^TEMPORARY.  ATTRIBUTE  .■(INTBSSBi. 
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SAC (RESUPPLY  AMMUNITION  CODE).  Attribute  of  an  SCL. V . ITEM 
which  points  to  a  specific  aaao  type  carried  by  the 
supply  unit. 

RDS. PKG  (ROUNDS  PACKAGE).  Attribute  of  a  SCL. V. ITEM 

specifying  the  nuaber  of  rounds  on  an  anao  pallet. 

RQTY (RESUPPLY  QUANTITY).  Attribute  of  a  RES. REQ  holding  the 
total  quantity  reguested  by  a  unit. 

SPRIORITY (SUPPLY  PRIORITY) .  Attribute  of  a  RES. REQ 

specifying  the  urgency  of  need  for  the  anao  request. 

TEMPORARY  ATTRIBUTE  (REAL) 

CO.  PKG  (CUBE  PACKAGE).  Attribute  of  a  SCL. V. ITEM  specifying 
the  cube  of  an  aaaunition  pallet. 

BT. PKG (WEIGHT  PACKAGE).  Attribute  of  a  SCL. V. ITEM  specifying 
the  weight  of  an  aaaunition  pallet. 


PROGRAM  LISTING 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 


ROUTINE  PHI. RESUPPLY  GIVEN  HT.  AVAIL, CU.  AVAIL,  A 

YIELDING  MUL1 , MUL2,LON1 , LON2 
DEFINE  A.LON1.LON2  AS  INTEGER  VARIABLES 
DEFINE  W1.W2. Cl. C2, WT. SHIP.CU. SHIP.MUL1 . MUL2 , 

HT • AVAIL ,6u. A VAIL, W2PCT,C2PCT, H 1 PCT, C1PCI 
AS  REAL  VARIABLES 
PRINT  1  LINE  THUS 
ROUTINE  PRI. RESUPPLY  CALLED 
"  DETERMINE  WEIGHT  AND  CUBE  REQUIRED 
••  FOR  LON1  6  LON 2  MISSIONS 


FOR  EVERY  RES. RE 
WITH  SPRIORITY  (R 
OR  SPRIORITY  (RE; 


IN  SWANT.  LIST  (A) 
S.REQ)  *1 


GO  TO  LI  ,L2 
'Ll*  LET  W1 


LET  Cl 


LET  LON  1 
CYCLE 
'  L2 '  LET 


fiS.REQ)  =  2,  DO 
PER  SPRIORITY (RES. REQ) 

*  W1  ♦  WT.PKGjSCODE(I, 

♦RQTY (RES. REQ I 

/RDS.PKGiSCODE(A.RAC(RES.REQ) 
♦_CU. PKG  j[SCODE  (A,  RAC  (RES.  REQ) )  ) 

8t(A,RAC(RES. REQ) ) ) 


C1  - 

*RQTY(RES.Rg 

/RDS. PKG (SCO 
*  1 


RAC  (RES.  REQ))) 

)) 


W2  *  W2  ♦  WT.PKG  (SCODE  (A,  RAC  (RES.  REQ) )  ) 


23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 


LET  C  2  *  C2 
*RQTY (RES . 
LET  L0N2  =  1 
LOOP 

LET  WT.  SHIP  = 
LET  CO. SHIP  * 

t « 

"DETER  IP  THE 
IP  (WT. SHIP  GT 
AND  L0N2  EQ  1 
LET  W2PCT  = 
LET  C2PCT  = 
"REDUCE  THE 
LET  M0L2 
LET  H0L1 

•  • 

"REDOCE 
IP  W2PCT 
AND  LONl 


Q) ) ) 


WT. SHIP  ♦  HI  ♦  M2 
CO. SHIP  ♦  C2  +  C2 


MIN  %  OF  LOR  2  ITEMS  ABE  SHIPPED. 
HT. AVAIL  OR  CO. SHIP  GT  CO. AVAIL) 


:  < 

LON 
LT 
E 


LET  W1PC$ 
LET  C1PCT 
LET  HOL1  = 
LET  HOL2  * 
ALWAYS 
ALWAYS 
RETURN 
END 


<WT.AVAIL-W1)/K2 
(CO.  AVAIL-Cli  /C2 
FILL  ON  L0N2  REQU IREMENTS 
MIN . P ( W2PCT, C2PCT , 1.0)  ) 

.0 

1  FILL  TO  ALLOW  MORE  SPACE 
C.L2WT  OR  C2PCT  LT  C.L2CU 
1 

*  (WT. AVAIL-W2*C.L2WT) /W1 
=  (CO.  AVAIL-C2*C.L2C0  /Cl 
MAX. P (WlPCT . C1PCT.C. L 1PCT) ) 
MIN.P(C.L2WT,C.L2C0f  1  .0)  ) 


Line  3-6  Define  recursive  variables  used  in  the  routine. 

Line  7  Prints  a  Message  marking  the  beginning  of  the 
routine. 

Lines  10-12  Begin  the  major  loop  of  the  routine  looping 
over  all  resupply  reguests  in  the  S-4's  want  list  and 
identify  the  priority  1  and  2  reguests.  Loop  ends  on 
line  28. 

Line  13  Transfers  control  based  on  the  priority  of  the 
request. 

Lines  14-16  Sum  the  total  weight  of  all  priority  1 
regues ts. 


Lines  17-19  Sum  the  total  cube  of  all  priority  1  requests 


Line  20  Indicates  the  presence  of  an  LON1  request. 

Line  21  Cycles  to  next  request. 

Lines  22-24  Sub  the  total  weight  of  all  priority  2 
requests. 

Lines  25-26  Sub  the  total  cube  of  all  priority  2  requests. 

Line  27  indicates  the  presence  of  an  LON2  request. 

Line  28  Ends  the  major  loop  begun  on  line  10.  Transfer  of 
control  is  either  to  the  next  request  or  out. 

Lines  29-30  Calculate  the  total  weight  and  cube  of 

outstanding  requests  due  to  priority  1  and  2  requests. 

Lines  32-39  Determine  if  all  priority  2  requests  have  been 
filled.  If  not,  it  establishes  a  multiplier,  Mul2,  to 
reduce  fill  on  priority  2  reguests  in  order  to  open  up 
space  on  trucks  to  fill  a  greater  number  of  LON2 
requests.  The  IF  check  ends  on  line  49. 

Lines  41-48  Check  aqain  to  see  if  all  LQN2  requests  have  at 
least  been  partially  filled.  If  not,  it  establishes  a 
multiplier,  M0L1,  to  reduce  the  fill  of  priority  1 
requests  to  open  up  space  on  trucks  until  the  priority  2 
requests  have  been  filled.  Priority  1  requests  will  be 
reduced  only  to  the  percentage  necessary  to  fill 
priority  2  requests,  or  to  a  user  designated  critical 
priority  of  fill  whichever  comes  first. 
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0. 


"EVENT  BAT. L. TIME" 


Event  BAT. L. TIME  is  initially  scheduled  in  the  »ain 
prograa  and  subsequently  reschedules  itself  each  day  of  the 
simulation.  The  event  is  used  to  start  and  end  a  battle  and 
to  schedule  moves. 

EVENT  SCHEDaLED 

HOVE 


siaBAiu.nmaus.ii&afism 

CNON (COMPANY  NUMBER)  .  Specifies  the  number  of 
COMPANY. COMMANDERS  created. 

RSTREAM (RESUPPLY  RANDOM  NUMBER  STREAM). 

WSTREAM (WEAPON  RANDOM  NUMBER  STREAM)  . 

S103Ak.ZABIABIJS_.l££Mtl 

B. END (BATTLE  END).  Termination  time  of  daily  battle. 
B.  START  (BATTLE  START).  Start  time  of  daily  battle. 


L1ML 


TIME. V 


TEMPORARY  ATTRIBUTE  (INTEGER) 

MARCH. ORDER.  Argument  for  the  event  move  holding  the  pointer 
of  the  company  receiving  orders  to  move. 


I  -  Loop  index. 


ROUTINES  CALLED 
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4 

* 


RANDOM. F,  TRUNC.F,  and  UNIFORM.? 


PROGRAM  LISTING 

1  EVENT  BAT. L. TIME 

2  " 

3  DEFINE  I  AS  AN  INTEGER  VARIABLE 

4  PRINT  1  LINE  WITH  TIME.V  THUS 

EVENT  BAT. L. TIME  CALLED  AT  TIME.V  *  *.**♦* 

5  * » 

6  LET  B.  START  *  TRUNC.  F  (TIME.  V) 

♦UNIFORM. F (0.0. 1 .00, WSIREAM) 

7  LET  B. END  *  S. START  +.25 

8  IF  B.  END  LT  T RUNC .  F  (TIM E .  V)  ♦  1.0, 

9  RESCHEDULE  A  BAT. I. TIME  AT  TRUNC.F  (TIME.V)  +1.0 

10  ELSE 

11  RESCHEDULE  A  BAT. L. TIME  AT  B. END 

12  ALWAYS 

13  FOR  I  «  1  TO  CNUM,  DO 

14  IF  RANDOM. F  (RST&EAM)  LT  .8, 

15  SCHEDULE  A  MOVE (I)  AT  B. END  ♦  .1 

16  PRINT  3  LINES  WITH  I  THUS 

!!!!!  1 !!!  i !!!!!!!!!!!  t If! f I 
MOVE  SCHEDULED  FOR  COMPANY  * 

!  I!! !!!!!!!!!!!!  !!  I  HI  !1  !! ! 

17  ALWAYS 

18  LOOP 

19  RETURN 

20  END 


Line  3  Defines  the  recursive  variable  used  in  the  routine. 

Line  4  Prints  a  aessage  aarking  the  start  of  the  routine. 

Line  6  Randoaly  picks  a  battle  start  tiae  over  the  24  hour 
period. 

Line  7  Schedules  a  battle  stop  tiae  6  hours  later. 

Lines  8-12  Reschedule  the  battle  for  the  next  day. 

Lines  13-18  Randoaly  select  a  coapany  to  aove  at  the  end  of 
a  day's  battle(event  MOVE).  Print  a  aessage  identifying 
the  unit. 
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P.  "EVENT  HOVE" 

Event  MOVE  is  scheduled  in  event  BAT. L. TIME.  The  event 
only  takes  place  after  a  battle  and  is  used  solely  to 
schedule  and  exercise  the  redistribution  logic. 

ARGUMENTS 

MARCH. ORDER.  Argument  for  event  MOVE  holding  the  pointer  of 
the  company  receiving  orders  to  aove. 

GLOBAL  VARIABLE  (INTEGER) 

PLATOON. LEADER 

S££ 

CO.  UNIT  (COMPANY  UNIT). 

l&SEQUSLJIlilBiaUUimSSiL 

C  -  Holds  the  value  of  the  coapany  currently  aoving. 

DISTR (DISTRIBUTOR) .  Arguaent  for  event  REDISTRIBUTE  holding 
the  value  of  the  unit's  PLATOON. LEADER. 

EVENT  SCHEDULED 
REDISTRIBUTE 

1  UPON  MOVE  (C) 

2  NORMALLY  MODE  IS  INTEGER 

3  FOB  EVERY  PLATOON.  LEADER  IN  PLAT. UNIT  (C)  ,  DO 

4  SCHEDULE  A  REDISTRIBUTE (PLATOON. LEADER)  NON 

5  LOOP 

6  RETURN 

7  END  v 

EXPLANATION  OF  CODE 

Line  2  Defines  the  aode  as  integer. 


211 


Lines  3-5  Schedule  a  move  for  each  platoon  in  the  cospan/ 


Q.  "EVENT  CO. RESUPPLY. *83" 

Event  CO . he SO PPL! . AES  is  scheduled  fro*  event 
UP. S4. ANNO.  The  event  distributes  the  aaaunition  assets 
received  by  a  company  to  subordinate  platoons  according  to 
their  aost  re  ent  LON.  It  then  sends  the  SSV/convoy  back  to 
the  battalion  trains  after  an  appropriate  ti«e  delay 
siaulating  a  delivery  froa  the  ATP/ASP. 

AfiSaflMI 

CNVY  (CONVOY)  .  Argument  of  CO.BESUPPLT.  APB  (COMPANY  RESUPPLY 
ARRIVE)  carrying  the  pointer  of  the  convoy  arriving. 
CO.CNVY  (COHPANI  CONVOY).  Argument  of  the  event 

CO. RESUPPLY. ARR  (COMPANY  BESOPPLY  ARRIVE)  holding  the 
pointer  value  for  the  convoy  arriving  in  the  area. 
BIEIM-IS-aBAS 

ANNO  1 .  AP. TOW (A RROR  PIERCING/TON  ROUNDS)  . 

ANN  02 .  HE.  DRAG  (HEAT/DBAGON  ROUNDS). 

ANNO  3.  AVI .  OR.  NSL3  (ALTERNATE  WEAPON  1  OR  NISSILE  3). 

AHN04.  AW2. OR. ADH (ALTERNATE  WEAPON  2  OR  AIR  DEFENSE 
NISSILE)  . 

EVENTS  SCHEDULED 
BN. ARRIVE (BATTALION  ARRIVE). 


PCODE (PLATOON  CODE)  (2-d)  .  Holds  the  pointer  value  for  a 
platoon's  PCL.V. ITEMS (PLATOON  CLASS  V  ITEMS). 

PLATOON. LEADER 

RES.REQ  (RESUPPLY  REQUEST). 

TANK 

TSTREAM  (TRIP  RANDOM  NUMBER  STREAM). 

GLOBAL  VARIABLES. (REAL) 

CCODE  (COMPANY  AMMUNITION  CODE). 

HAXTBIP (MAX  TRIP).  The  aaxiaua  tiae  required  for  a  convoy  to 
reach  its  intended  destination. 

M INTRIP  (MIN  TRIP).  The  ainiaua  tiae  required  for  a  convoy  to 
reach  its  intended  destination. 
fflBBMBK.  *-30133X15-11  &&L 

TIME. V 

RECURSIVE  VARIABLES  (INTEGEB) 

ASSETS.  Bolds  the  aaount  of  aaao  left  to  be  issued. 

DEL.  Bolds  the  aaount  of  aaao  initially  delivered. 

NO. BATTLE.  Indicates  whether  RES.REQs  should  be  filled. 

"0”  indicates  no 
"1n  indicates  yes 

TEMP.  Place  holder  for  release  point  of  the  convoy. 

COM.  AMMO,  IN?.?,  P. CLASS. V 


213 


SST5  USED 

C.CGO. LIST (CONVOY  CARGO  LIST). 

CO. QUIT (COMPANY  UNIT) . 

CHANT. LIST (COMPANY  HANT  LIST). 

PLAT. UNIT (PLATOON  UNIT). 

SREQN. LIST  (SUPPLY  REQUISITION  LIST). 

SHANT.  LIST  (SUPPLY  HANT  LIST). 

TNK . ALIYS (TANK  ALIVE) . 

AMM05 (AMMUNITION  5).  Of  TANK. 

AMH06 (AMMUNITION  6).  Of  TANK. 

AP. TOH ( ARMOR-PISRCING/TOH) .  Ammunition  1  OF  TANK. 

TAC1 . (TANK  AMMUNITION  CODE  1). 

TAC2. (TANK  AMMUNITION  CODE  2). 

TAC3. (TANK  AMMUNITION  CODE  3). 

TAC4. (TANK  AMMUNITION  CODE  4). 

TAC5.  (TANK  AMMUNITION  CODE  5). 

TAC6 . ( TANK  AMMUNITION  CODE  6). 

AH1 . OR . MSL3 ( ALTERN ATE  HEAPON  1  OB  MISSILE  3).  Ammunition  3. 
AH2. OR. ADM (ALTERNATE  HEAPON  2  OR  AIR  DEFENSE  MISSILE) . 
Ammunition  4. 

C. MV. STATE  (CONVOY  MOVEMENT  STATE). 
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C. SHORT  (COMPANY  SHORTAGE).  Total  rounds  short  for  a  type 
ammo . 

COCDR (COMPANY  COMMANDER).  Of  TANK. 

FKILL (FIREPOWER  KILL)  . 

FLAG  Yielding  arguaent  of  W.AMMO  and  COM. AMMO,  not  used  in 
this  routine. 

HE. DRAG (HEAT/DRAGON  ROUNDS).  Aaaunition  2  of  TANK. 

KKILL  (CATASTROPHIC  KILL). 

MKILL (MOBILITY  KILL). 

OH1 (ON-HAND  1).  Current  balance  of  aaaunition  1  on  a  TANK. 

OH2 (ON-HAND  2).  Current  balance  of  aaaunition  2  on  a  TANK. 

OH3 (ON-HAND  3).  Current  balance  of  aaaunition  3  on  a  TANK. 

OH 4 (ON-HAND  4) .  Current  balance  of  aaaunition  4  on  a  TANK. 

0H5 (ON-HAND  5).  Current  balance  of  aaaunition  5  on  a  TANK. 

0H6 (ON-HAND  6).  Current  balance  of  aaaunition  6  on  a  TANK. 

P. short  (platoon  SHORTAGE).  Current  shortage  of  a  pcl.v.item 
(PLATOON  CLASS  V  ITEM) .  Unigue  to  each  platoon  and  aaao 
type. 

PCURR.  LOAD  (PLATOON  CURRENT  LOAD).  On-hand  balance  for  an> 
aaao  type.  Unigue  for  each  platoon  and  aaao  type. 

RAC (RESUPPLY  AMMUNITION  CODE). 
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RCNVY  (RESUPPLY  CONVOY).  Argument  of  the  event  BN.  ARRIVE 


(BATTALION  ARRIVE)  carrying  the  pointer  of  the  convoy. 

REQUESTOR.  Attribute  of  a  RES. REQ(RESUPPLY  REQUEST) 
specifying  the  unit  making  the  reguest. 

RFILL (RESUPPLY  FILL).  Attribute  of  a  RES.REQ  (RESUPPLY 

REQUEST)  specifying  the  amount  of  ammunition  released 
fill  a  request. 

RP (RELEASE  POINT).  Attribute  of  a  convoy  specifying  the 
convoy’s  destination. 

SLOAD1 (STONED  LOAD  1)  .  Optimal  load  ammo  type  1. 

SLOAD2  (STONED  LOAD  2)  .  Optimal  load  ammo  type  2. 

SLOAD3  (STONED  LOAD  3) .  Optimal  load  ammo  type  3. 

SL0AD4 (STONED  load  4).  optimal  load  ammo  type  4. 

SLOAD5 (STONED  LOAD  5).  Optimal  load  ammo  type  5. 

SL0A06 (STONED  LOAD  6) .  Optimal  load  ammo  type  6. 

SP (START  POINT).  Attribute  of  a  convoy  specifying  the 
convoy's  origin. 

STATUS.  Indicates  the  current  location  of  a  convoy. 

SYS.  TYPE  (SYSTEM  TYPE). 

ROUTINES  CALLED 

UNIFORM.?,  UP. DATE,  W.AHMO 

1  EVENT  CO. RESUPPLY. ARRtCNVY) 

2  DEFINE  FLAG, NO. BATTLE, TEMP, CMVY, ASSETS, 


AND  DEL  AS  INTEGER  VARIABLES 
PRINT  2  LINES  WITH  TIME. V, CNVY  THUS 
EVENT  CO. RESUPPLY. ARS  CALLED 
TIME. V  =  a*.**4*  CONVOY  *  **** 

•  t 

"BRING  THE  CONVOY  OUT  OF  HYPERSPACE 
LET  C. MV. STATE  (CNVY)  =  0 


FOR  EVERY  RSS.REQ  IN  C . CGO . LIST (CNVY)  ,  DO 
LET  ASSETS  =  RFILL  (RES .REQ) 

i  • 

FOR  EVERY  PLATOON.  LEADER 

IN  CO. UNIT  (REQUESTOR (RSS.REQ)  )  ,D0 
L ET  DEL- 

IMT  .  F  (P  .  SHORT (PCODE  (PLATOON.  LEADER, RAC  IRES.  REQ)  )  ) 
/ C .  SHORT (CCODE (REQUESTOR (RES .REQ) ,RAC  (RES. REQ) ) ) 
*  RFILLJRES.  REQ)*) 

LET  ASSETS  —  ASSETS  —  DEL 

LET  PCORR.LOAD(PCODE(PLATOON. LEADER, RAC (RES. REQ)  ) )  = 
fPCURR. LOAD (PCODE  (P LATOON . LEADER, RAC  (RES. REQ) ) ) ♦DEL 

• 'FILL  TANKS 

FOB  EVERY  TANK  IN  PLAT. UNTT(PLATOON. LEADER) ,  DO 
IF  SKILL  (TANK)  =1  OB  MF KILL  (TANK)  =1 


(RES.  EEC)  )  ) 
(RES.  REQ)  )  ) 


IF  SKILL  (TANK) 
OR  FKILL  (TANK) 
CYCLE 
OTHERWISE 


KKILL 


C  (TANK)  = 
(TANK) 


IF  TAC1  (TANK) 
LET  OH 1 (TAN 


ANK)  aRAC  (RSS.REQ) 
(TANK)  =  OH1 (TANK) 


<  (SLOAD1  (TANK)  -OH1  (TANK)  )  )  / 
P . SHORT (PCODE (PLATOON .LEADER , RAC (HES. REQ)  ) ) 
LET  AMMOf  (TANK)*  AMMOI  (TANK)  +DEL 

MSLOAD1  (TANK) -AMMOI  (TANK))  )  / 
P. SHORT  (PCODE  (PLATOON. LEADER, RAC  (RES.  REQ)  ) ) 
‘ ‘ KLOOP 


P. SHORT  ( 
GO  TO  TAN 
OTHERWISE 


IF  TAC2 
LET  01 


2  (TA 


=  RAC  (RES.  REQ) 
K)  *0H2  (TANK)  ♦ 


P. SHORT (PCODE ( 
LET  AHH02  (TANK 

P.  SHORT  (PCODE 
GO  TO  TANKLOOP 


0H2  (TANK)  ♦  DEL 
<  (SL0AD2 (TANK 
PLATOON. LEADE 


-0H2 (TANK) ) )  / 
RAC  (RES.  REQ)  ) 


'AMM02  ( 
(SL0AD2 


u  awiu  Lta.  m  an' 

TANK)  +  DEL 


*  (SL0AD2 (TANK)  -AMHO 
(PLATOON.  LEADER,  RAC 


ASS02  (TANK 
, RAC  (RES.  R 


OTHERWISE 

IF  TAC3  (TANK 
LET  0H3(TA 


) ZRAC  (RES . RE( 
NK)  =  0H3 (TA) 
t  (SLOAD • 


K)  ♦  DE. 
(TANK[- 


LET  0H3 (TANK)  =  0H3 (TANK)  ♦  DEL 

< (SL0AD3 (TANKJ-0H3 
?. SHORT (PCODE  (PLATOON . L EADER, RAC 
LET  AMMO 3 (TANK) =AHM03 (TANK7+DEL 

*  (SL0AD3  (TANK) -AMMO 
P. SHORT (PCODE (PLATOON. LEADER, RAC 
GO  TO  TANKLOOP 
OTHERWISE 


DEL 

)  -OH 3  (TANK) 


P. SHORT (PCODE (PLATOON. LEADER, RAC 
0  TO  TANKLOOP 


ammo3(tank: 


(ES .  R. 


IF  TAC4  (TANK) *RAC (RES.  RE 
LET  0H4 (TANK)  *  0H4(TA 
< (SLOA 

. SHORT (PCODE (PLATOON 
T  AMM04 (TANK) *AMM04 ( 
MSL0AD4 
.SHORT  (PCO DE (PLATOON 


*  0H4 (TANK)  ♦  DEL 

<  (SL0AD4  (TANK)  -0H4  (TANK) )  )  / 
(PLATOON. LEADER, RAC  (RES.  REQ)  ) ) 
)  *AMM04  (TANK)  ♦DEL 
SL0AD4  (TANK)  - 


P. SHORT (PCODE 


GO  TO  TA 
OTHERWISE 


IKLOOP 


SL0AD4 (TANK 
LATOON. LEAD 


-AMM04  (TANK; 

;r,rac(res.r 


iyr» 


217 


IF  TAC5  (TANK)  S££AC  (RES .  REQ) 

LET  0H5 (TANK)  =  0H5 (TANK)  ♦  DEL 

<  (SL0AD5  (TANK)  -0H5  (TANK))  )  / 
P. SHORT (PCODE (PLATOON . LEADER, EAC (RES . EEC) )  ) 

LET  AMM05  (TANK)  =AMN05  (TANK)  ♦DEL 

t  (SLOAD5  (TANK) -AMM05  (TANK) )  )  / 
P.  SHORT  (PCODE  (PLATOON.  LEADER, SAC  (EES  .  REQ) )  ) 
GO  TO  TANKLOOP 
OTHERWISE 

IF  TAC6  (TANK) -RAC  (RES.  REQ) 

LET  0 H6 (TANK)  =  OH6 (TANK)  ♦  DEL 

<  (SLOAD6  (TANK) -OH6  (TANK))  )  / 
P. SHORT (PCODE (PLATOON . L EADER , RAC  (RES. REQ) ) ) 

LET  AMMOo  (TANK)  =  AMM06 ( TANK) +DEL 

)  Ml  1  1,  f#  f  «  t,  U  M  y  a  ill  *  M  If  1  1  m 


_ _ _  )6  (TANK)  +DEL 

<SLOAD6 (TANKJ-AMM06  (TANK) ) 
P.  SHORT  'PCODE  (PLATOON.  LEADER, RAC  (RES.  REQ) 
ALWAYS 

•  • 

•TANKLOOP* 

LOOP 

*  UPDATEFILES • 

IF  RES. REG  IS  NOT  IN  SOME  SWANT.LIST 
AND  RES. REQ  IS  IN  SOME  CWANT.LIST, 

REMOVE  RES. REQ 

FROM  CW ANT . LIST (REQUESTOR (RES. REQ) ) 

ALWAYS 

i  • 

IF  RES. REQ  IS  NOT  IN  SOME  SSEQN.LIST 
PILE  RES. REQ  IN  SREQN .LIST  (SP (CNVY) ) 

ALWAYS 

LET  STATOS  (RES .  REQ)  =  "ATP" 

LET  DEL  *  0 
LOOP 
LOOP 

FOR  EVERY  TANK  IN  INK. ALIVE 
WITH  COCDR  (TANK)  EQ  RP  (CNVY)  ,DO 
IF  SIS. TYPE (TANK)  EQ  7, 

CYCLE 
OTHERWISE 
LET  NO. BATTLE  *  1 

CALL  W. AMMO  (TANK, NO. BATTLE)  YIELDING  FLAG 
LOOP 

i « 

FOR  EVERY  PLATOON.  LEADER  IN  CO.  UNIT  (HP  (CNVY) )  ,  DO 
CALL  P. CLASS. V (PLATOON. LEADER) 

LOOP 

LET  NO. BATTLE  =  1 

CALL  COM. AMMO (RP (CNVY) , NO. BATTLE)  YIELDING  FLAG 

'•SEND  THE  CONVOI  HOME 
LET  TEMP  =  RP  (CNVY) 

LET  RP  (CNVY)  *  SP(CNVY) 

LET  SP  (CNVY)  *  TEMP 

LET  C.MV.  STATE  (CNVY)  »  1 

SCHEDULE  A  BN .  ARRIVE  (CNVY) 

IN  UNIFORM .F (M1NTRIP,HAITRIP ,TSTSEAM)  MINUTES 
RETURN 
END 

EXPLANATION  OF  COpE 


INK)  EQ  7, 


Lines  2-3  Define  the  recursive  variables  used  in  the 
routine. 

Line  4  Prints  a  message  marking  the  start  of  the  routine. 

Lines  6-7  Change  the  convoy  movement  state  to  zero. 

Line  9  Begins  the  routine's  major  loop  over  all  resupply 
requests  in  the  arriving  convoys  cargo  list.  Loop  ends 
on  line  104. 

Line  10  Captures  the  quantity  delivered  by  the  convoy  as  a 
local  variable  for  computation  purposes. 

Lines  12-13  Begin  an  inner  loop  over  every  platoon  leader 
in  the  company  in  order  to  distribute  the  arriving 
supplies.  Loop  ends  on  line  103. 

Lines  14-17  Set  the  delivery  for  a  particular  platoon  equal 
to  [ plazoon  shortage  /  company  shortage]  multiplied  by 
the  deliver  quantity. 

Line  18  Subtracts  the  delivery  from  the  assets  available. 

Lines  19-20  Adjust  the  platoon  current  load  for  that  ammo 
type. 

Line  22  Begins  an  inner  loop  over  all  the  weapon  systems  in 
the  platoon  so  that  deliveries  can  be  made.  Loop  ends  on 
line  89. 
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Lines  24-27  Determine  if  any  vehicle  has  sustained 

casualties,  if  so,  the  loop  is  cycled  to  the  next  weapon 
system. 

Lines  29-86  Check  to  see  if  the  ammo  delivered  is  one  of 
the  six  carried  on  the  TANK.  If  so,  the  weapon  system’s 
on-hand  knowledge  and  actual  knowledge  is  updated  to 
reflect  the  delivery. 

Lines  88-89  Close  the  combat  vehicle  loop  begun  on  line  22. 
Transfer  of  control  goes  to  the  next  TANK  or  out  to  the 
next  platoon. 

Lines  91-101  Update  files  by  removing  the  request  from 
company  want  lists  and  filing  the  same  request  on  a 
supply  request,  simulating  a  request  from  battalion  to 
the  brigade  ATP  for  more  ammo. 

Line  102  Resets  the  delivery  quantity  to  zero. 

Line  103  Closes  out  the  platoon  loop  begun  on  line  12. 

Transfer  of  control  is  to  the  next  platoon  or  out  to  the 
next  request. 

Line  104  Closes  out  the  request  loop  begun  on  line  9. 
Transfer  of  control  is  to  the  next  request  or  out. 

Lines  105-112  Cause  every  TANK  in  the  company  to  update  its 
ammo  status. 
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Lines  114-116  Cause  every  platoon  in  the  coapany  to  update 


its  aaao  status. 

Lines  117-118  Cause  the  coapany  to  update  its  aaao  status. 
Lines  120-126  Turn  the  convoy  around  and  sends  it  back  to 
the  battalion  supply  point  as  a  resupply  coaing  froa  the 
&TP. 

R.  "EVENT  REDISTRIBUTE" 

This  event  is  scheduled  froa  event  HOVE.  It  is  used  to 
evenly  redistribute  aaaunition  in  a  platoon. 

ARGUMENTS  (INTEGER) 

P  -  Holds  the  pointer  value  of  the  platoon  currently 
redistributing. 

DISTR (DISTRIBUTOR) .  Arguaent  for  the  event  REDISTRIBUTE 
holding  the  value  of  the  unit’s  PLATOON. LEADER. 


( 


DEFINE  TO  MEAN 

AMH01 .  AP.  TOW  (ARMOR  PIERCING/TOW  ROUNDS). 

AMH02.  HE. DRAG (HEAT/DRAGON  ROUNDS). 

ANH03.  AH1 .OR. MSL3 (ALTERNATE  WEAPON  1  OR  MISSILE  3). 
AMM04.  AW2. OR. ADM (ALTERNATE  WEAPON  2  OR  AIR  DEFENSE 
MISSILE)  . 


PCL.V. ITEM 
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PCODE (PLATOON  CODE)  (2-d)  .  Holds  the  pointer  value  for  a 
platoon's  POL. V. ITEMS (PLATOON  CLASS  V  ITEMS). 

TANK 

PERMANENT  ATTRIBUTE  (SEAL) 

TIME. 7 

HE  CJMLVE  J.hUMkZ-liZUSML 

CASSETS.  Current  amount  of  an  ammo  type  on-hand  in  a 
platoon. 

FLAG.  Yielding  arguaent  for  routine  H.AMHO;  not  used  in  this 
routine. 

NO. BATTLE.  Indicates  whether  RES.REQs  should  be  filled. 

"0"  indicates  no 
"1"  indicates  yes 

RASSETS.  Required  amount  of  an  aaso  type  based  on  the 
platoons  stowed  load. 

&0SXISgS.C4U,3D 

P. CLASS. ¥,  OP. DATE,  M.AHMO 

SETS  OS ED 

PLAT. ONIT (PLATOON  ONIT) .  Owned  by  a  PLATOON. LEADER.  Members 
are  the  unit's  coabat  vehicles (TANKS) . 

PLT. AMMO  (PLATOON  AMMUNITION)  .  Owned  by  a  PLATOON. LEADER. 
Members  are  the  unit's  PCL .T. ITEMS (PLATOON  CLASS  7 
ITEMS)  . 


x£Ami£X-ix2mm.j2ix£sm 


AMM05  (AMMUNITION  5). 

AMM06 (AH HO NIT ION  6). 

AP. TOW (ARMOR-PIERCING/TOW) .  Aaaunition  1 
TAC1 . (TANK  AMMUNITION  CODE  1). 

TAC2. (TANK  AMMUNITION  CODE  2). 

TAC3. (TANK  AMMUNITION  CODE  3). 

TAC4. (TANK  AMMUNITION  CODE  4). 

TAC5. (TANK  AMMUNITION  CODE  5). 

TAC6 . (TANK  AMMUNITION  CODE  6). 

AW1. OR. HSL3 (ALTERNATE  WEAPON  1  OR  MISSILE  3).  Aaaunition  3. 
AW2.03. ADM  (ALTERNATE  WEAPON  2  OR  AIR  DEFENSE  MISSILE). 

Aaaunition  4. 

PKILL (FIREPOWER  KILL). 

HE. DRAG (HEAT/DRAGON  ROUNDS).  Aaaunition  2. 

KKILL (CATASTROPHIC  KILL). 

HFKILL  (MOBILITY  AND  FIREPOWER  KILL). 

MKILL (MOBILITY  KILL). 

PAC (COMPANY  AMMUNITION  CODE). 

PCURR.  LOAD  (PLATOON  CURRENT  LOAD).  On-hand  balance  for  an 
aaao  type. 

PL. B. LOAD (PLATOON  BASIC  LOAD). 

SLOAD1  (STOWED  LOAD  1).  Optiaal  load  aaao  type  1. 

SLOAD2  (STOWED  LOAD  2).  Optiaal  load  aaao  type  2. 
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SL0AD3  (STOWED  LOAD  3).  Optimal  load  ammo  type  3. 

SL0AD4  (STOWED  LOAD  4).  Optimal  load  ammo  type  4. 

SLOAD5  {STOWED  LOAD  5).  Optimal  load  ammo  type  5. 

SLOAD6 (STOWED  LOAD  6) .  Optimal  load  ammo  type  6. 

PROGRAM  LISTING 


EVENT  REDISTRIBUTE (P) 

DEFINE  NO . BATTLE# R ASSETS ,C ASSETS , ROUND, 

FLAG, AND  P  AS  INTEGER  VARIABLES 
PRINT  1  LINE  WITH  TIME.V  AS  FOLLOWS 
EVENT  REDISTRIBUTE  CALLED  AT  TIHB.V  *  **.**** 
•  • 

FOB  EVERT  TANK  IN  PLAT.  UNIT  (P)  fDO 
LET  NO. BATTLE  »  1 

CALL  W.AHHO  (TANK, NO. BATTLE)  YIELDING  FLAG 

LOOP 

•  • 


|fLET  RASSETS  *  PL. B. LOAD (PCODE (P, fiOUN 

FOR  EVERT  TANK  IN  PLAT.UNIT(P) .DO 
IF  HKILL  (TANK)  =1  OR  BFKILL  (TANK)  *1 
OR  FKILL  (TANK)  »1  OR  KKILL  (TANK)  *  1 
CYCLE 
OTHERWISE 


OTHERWISE 

IP  TAC1  (TANK)  *  PAC  (PCL.  V .ITEM) 

LET  AHHOI (TANK) xSLOAD1 (TANK) /R ASSETS*CASSETS 
CYCLE 
ALWAYS 

IF  TAC2  (TANK)  *  PAC  (PCL.  f .  ITEH) 

LET  AMH02 (TANK)  »  SLOAD1 (TANK) /BAS SETS*C ASSETS 
C  YCL  E 
ALWAYS 

IF  TACIfTANK)  »  PAC  (PCL.  V.  ITEH) 

LET  AHHOI (TANK)  -  SLOAD1 (TANK) /RASSETS*CASSETS 
CYCLE 
ALWAYS 

IF  TAC2  (TANK)  *  PAC  (PCL. ?. ITEH) 

LET  AnR02  (TANK)  *  SLOAD2 (TANK) /RA5SETS*C  ASSETS 
CYCLE 
ALWAYS 

IP  TAC3  (TANK)  *  PAC  (PCI.  V.  ITEH) 

LET  AHH03 (TANK)  *  SLOAD3 (TANK) /RASSETS*CASSETS 
CYCLE 
ALWAYS 

IF  TAC4  (TANK)  *  PAC  (PCL.  V. ITEH) 

LET  AHH04  (TANK)  *  SLOAD4 (TANK) /RASSETS*CASSETS 
CYCLE 
ALWAYS 

IF  TAC5  (TANK)  *  PAC  (PCL. f. ITEM) 

LET  AHH05  (TANK)  *  SLOADS (TANK) /BASSET S*CASSETS 
CYCLE 
ALWAYS, 

IF  TAC6  (TANK)  *  PAC  (PCL.  V. ITEH) 

LET  AHH06 (TANK)  »  SLOAD6 (TANK) /RASSETS*CASSETS 
C  Y  CLE 
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52 

53 

54 

55 

57 

58 

59 

60 
61 


ALNAYS 

LOOP 

LOOP 

FOR  EVERY  TANK  IN  PLAT .  UNIT  (P)  ,  DO 
LET  NO. BATTLE  *  1 

CALL  W. AMMO  (TANK, NO. BATTLE)  YIELDING  FLAG 
LOOP 

CALL  P. CLASS. V 

RETURN 

END 

EXPLANATION  OF  CODE 


Lines  2-3  Define  recursive  variables  for  use  in  the 
routine. 

Line  4  Prints  a  message  aarlcing  the  beginning  of  the 
rout  ine. 

Lines  6-9  Update  the  platoon  weapon  system's  current 
knowledge  of  its  aano  status. 

Line  11  Updates  the  platoon's  current  anno  knowledge. 

Line  12  Begins  the  major  loop  for  the  routine  by  looping 

over  all  aaao  types  carried  by  the  platoon.  Loop  ends  on 
line  54. 

Lines  13-14  capture  the  current  assets  on-hand  and  the 
required  assets  needed  to  be  on-hand  for  coaputations. 

Line  16  Begins  an  inner  loop  for  the  routine  looping  over 
all  weapon  systeas  in  the  platoon.  Loop  ends  on  line  53. 

Line  17-20  Check  if  a  weapon  has  sustained  battle  damage. 

If  so,  the  routine  cycles  to  the  next  weapon. 
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Lines  21-52  Check  if  the  anno  being  considered  is  one  of 
the  weapons  six  ammunitions  carried.  If  so,  the  weapon 
is  given  a  percentage  of  the  assets  on-hand  egual  to 
[weapon  stewed  load  /  platoon  base  load]  multiplied  by 
the  platoon’s  assets. 

Line  53  Closes  out  the  inner  loop  causing  the  routine  to 

loop  to  line  16  and  the  next  weapon  or  out  to  the  next 

aaao . 

Line  54  closes  out  the  major  loop  causing  the  routine  to 

loop  to  line  12  and  the  next  aaao  type  or  out. 

Lines  55-58  Cause  every  TANK  in  the  platoon  to  update  its 
aaao  status. 

Line  59  Causes  the  platoon  to  update  its  aaao  status. 

S.  "EVENT  BN .ARRIVE" 

Event  BN.ABBIVE  is  scheduled  froa  CO .RESUPPLY. ABB  to 
simulate  an  BSV  or  convoy  returning  to  the  battalion  trains 
after  a  resupply  mission.  The  BSV  or  convoy  returns  to  the 
battalion  trains  with  an  identical  cargo  to  what  it 
delivered  to  the  resupplied  coapany.  Understandably,  this 
is  unrealistic  but  it  serves  the  purpose  of  resupplying  the 
battalion  trains  in  the  aodel.  This  cargo  is  now  added  to 
the  battalion's  assets  and  becomes  available  for  resupply 
again. 
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ARGUMENTS 

RCNVY (RESUPPLY  CONVOY).  Argument  of  the  event  3N. ARRIVE 

(BATTALION  ARRIVE)  carrying  the  pointer  of  the  convoy. 

EVENT? .  SCHEDULE}) 

BN. ARRIVE (BATTALION  ARRIVE). 

GLOBAL  VARIABLES  (INTEGER) 

SCODE  (SUPPLY  CODE)  (2-d) .  Holds  the  pointer  value  for  a 
supply  unit's  SCL .V. ITEMS (SUPPLY  CLASS  V  ITEMS). 

TANK 

PERMANENT  ATTRIBUTES 

TIME. V 

SETS 

CARGO.  Of  a  resupply  truck. 

C.CGO. LIST  (CONVOY  CARGO  LIST).  Owned  by  a  convoy.  Members 
are  the  RES. REQs (RESUPPLY  REQUEST)  being  shipped. 

ELEMENTS.  Owned  by  a  CONVOY.  Members  are  trucks  (TANKS) 
belonging  to  the  convoy. 

SCONVOY  (SUPPLY  CONVOY).  Owned  by  a  SUPPLY. OFFICER.  Members 
are  CONVOY  (s). 

SREQN. LIST  (SUPPLY  REQUISITION  LIST).  Of  a  RES.REQ. 

TEMPORARY  ENTITIES 

CONVOY 

RES.REQ.  (RESUPPLY  REQUEST). 


T.CGO (TRUCK  CARGO) 


TEMPORARY  ATTRIBUTES  (INTEGER) 

C.  MV.  STATE  (COMPANY  MOVEMENT  STATE). 

ONHAND 

RAC (RESUPPLY  AMMO  CODE). 

RFILL (RESUPPLY  FILL).  Attribute  of  a  HES.REQ  (RESUPPLY 

REQUEST)  specifying  the  aaount  of  aaaunition  released  to 
fill  a  request. 

RP (RELEASE  POINT).  Attribute  of  a  CONVOY  specifying  the 
convoy's  destination. 

RQTY (REQUIRED  QUANTITY).  Of  a  RES. REQ. 

ROUTINES  CALLED 

UP. DATE 


ffi9S3AS-i.I5.g3S 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

a 

23 

24 


EVENT  BN . ARRI VE (RCNVY) 

DEFINE  RCNVY  AS  AN  INTEGER  VARIABLE 
PRINT  1  LINE  WITH  TIHE.V  THUS 

EVENT  BN. ARRIVE  CALLED  AT  TIHE.V  »  **.**** 
LET  C.HV. STATE (RCNVY)  *  0 
FOR  EVERY  RES. REQ  IN  C. CGO. LIST (RCNVY) , DO 
ADD  RFILL7rES.  REQ)  TO 
ONHAND  (SCODEJHP (RCNVY)  .RAC (RES .REQ) ) ) 
REMOVE  RES. REQ  FROM  C. CGO. LIST  (RCNVY) 
REMOVE  RES.  RED  FROM  SREQN . LIST  (RP  (RCNVY) ) 
IF  RQTY (RES. REQ)  *  0, 

DESTROY  RES. REQ 
ALWAYS 


?OR  EVERY  TANK  IN  ELEMENTS  (RCNVY)  ,  DO 
FOR  EVERY  T.CGO  IN  CARGO  (TANK).  DO 
REMOVE  T.CGO  FROM  CARGO (TANK) 
DESTROY  T.CGO 
LOOP 

REMOVE  TANK  FROM  ELEMENTS  (RCNVY) 

LOOP 

REMOVE  RCNVY  FROM  SCONVOI (RP (RCNVY) ) 
DESTROY  CONVOY  CALLED  RCNVY 
BETURN 
END 
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EX PL A  NATION  OP  CODE 


Line  2  Defines  recursive  variables  used  in  the  routine. 

Line  3  Prints  a  message  indicating  that  the  routine  has 
been  called. 

Line  4  Changes  the  convoy  move  state  to  zero. 

Lines  5-13  Loop  over  every  resupply  reguest  in  the  convoy 
adding  its  fill  to  the  on-hand  stocks  at  the  battalion, 
removing  it  froa  the  convoy  cargo  list  and  the  S-4*s 
request  list.  If  the  out  standing  balance  for  the 
request  is  zero  it  is  destroyed. 

Lines  14-20  Loop  over  every  TANK  in  the  convoy's  elements 
removing  the  cargo  entities  froa  the  trucks,  and  the 
trucks  froa  the  convoys.  The  cargo  entity  is  then 
destroyed. 

Lines  21-22  Reaove  the  convoy  froa  the  S-4's  list  and 
destroys  the  convoy. 

T.  "EVENT  OP.B.AHHO" 

Event  OP. w. ARNO  is  initially  scheduled  in  routine 

BLO. CREATE  for  each  weapon  systea  in  the  model.  It  is  used 

to  call  routine  ir.AHHO  for  a  periodic  update  of  aaao  LONs. 

It  subsequently  randomly  reschedules  itself  siaulating  the 
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irregular  counting  of  ammunition  during  combat.  Based  on  a 
returning  argument  frca  routine  H.AMMO,  this  event  may 
schedule  a  platoon  update  if  the  weapon  is  critical  for  an 
aano  type,  or  may  stop  scheduling  updates  for  the  weapon  if 
damage  has  been  sustained. 

ARGUMENT  (INTEGER) 

RND.CNTR.  Points  to  weapon  currently  updating. 

GLOBAL  VARIABLE _ (INTEGER) 

MSTREAM  (WEAPON  RANDOM  NUMBER  STREAM). 


UMAX  (WEAPON  MAXIMUM).  The  maxiaua  tiae  that  can  pass  before 
a  weapon  will  update  its  ammunition  status. 

WMIN  (WEAPON  MINIMUM).  The  minimum  time  that  can  pass  before 
a  weapon  will  update  its  ammunition  status. 


FLAG,  fielding  argument  from  W.AMMO. 

UNIFORM. F,  UP.PLT. AMMO  (UPDATE  PLATOON  AMMO) 


TIME.? 


PERMANENT  ATTRIBUTE  (REAL) 


TEMPORARY  ATTRIBUTE  (INTEGER) 


A  -  Holds  pointer  of  weapon  currently  updating. 


PLTLDR.  Of  TANK. 
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P.RND.  CNTR (PLATOON  ROUND  COUNTER).  Arguaent  Of  event 


UP. PLT. AMMO  pointing  to  a  specific  platoon  which  will 


update . 


PROGRAM  LISTING 


1  EVENT  UP.  W.  AMMO  (A) 

2  DEFINE  NO. BATTLE. A,  AND  FLAG  AS  INTEGER  VARIABLES 

3  LET  NO. BATTLE  =  0 

4  CALL  W.AMMO  GIVEN  A. NO. BATTLE  YIELDING  FLAG 

5  IF  FLAG  =  100,  ' ’ EMERGENCY  RESUPPLY  NEEDED 

6  SCHEDULE  AN  UP .  PLT .  AMMO (PLTLDR  (A) )  NON 

7  PRINT  2  LINES  WITH  TIME.V  THUS 

UP. PLT. AMMO  CALLED  BECAUSE  OF  ZERO  BAL 
TIME.V  *  *».**•* 

8  ALWAYS 

9  IF  FLAG  NE  1,  "NO  BATTLE  DAMAGE  SUSTAINED 

10  SCHEDULE  AN  UP.  W.  AMMO  (A) 

11  IN  UNIFORM.?  (HMIN, WMAX.WSTREAM)  HOURS 

12  ALWAYS 

13  RETURN 

14  END 

EXPLANATION  OF  CODE 


Line  2  Defines  recursive  variables  for  the  routine. 


Line  3-4  Set  the  index  necessary  to  call  for  a  battle 


update  and  calls  routine  W.AMMO. 


Lines  5-8  If  the  flag  returned  indicates  that  a  weapon  is 


at  eapty  for  an  aaaunition  type,  this  provokes  a  call 


for  the  platoon  to  update  its  aaao. 


Lines  9-11  If  the  flag  indicates  that  no  battle  daaage  has 


been  sustained,  the  update  is  rescheduled. 


U.  "EVENT  UP. PLT. AMMO" 


This  event  is  initially  scheduled  froa  routine 


BLU. CREATE  to  call  routine  P. CLASS. V  for  a  periodic  aaao 
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update.  It  then  randomly  reschedules  itself  in  order  to 
*  simulate  a  platoon  leader  checking  individual  weapons. 

Scheduling  also  occurs  if  a  weapon  reaches  an  LON  of  "1"  for 
an  ammunition  type  simulating  the  initiation  of  an  emergency 
request.  Additionally,  based  on  a  return  argument  from 
routine  P. CLASS.?,  this  event  may  schedule  a  company  update 
if  the  platoon  is  critical  for  an  ammo  type,  or  may  stop 
scheduling  updates  for  the  platoon  if  all  its  weapons  are 
incapacitated. 

AssaaBflS-iiaisssaL 

P.RND. CNTH  (PLATOON  HOUND  COUNTEH) .  Argument  of  the  event 
UP. PLT.AHHO (UPDATE  PLATOON  AMMUNITION)  carrying  the 
pointer  value  of  the  platoon  currently  updating. 

SET 

PLT.AHHO  (PLATOON  AHHONITION)  .  Owned  by  a  PLATOON. LEADER. 
Members  are  the  unit's  PCL.V. ITEMS (PLATOON  CLASS  V 
ITEMS)  . 

EVENT  NOTICE 

UP.COM. AHHO(OPDATE  COMPANY  AMMUNITION). 

PSTREAM (PLATOON  RANDOM  NUMBER  STREAM) . 
giQB  AL_  .VARIABLES  -16BALL 

( 
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PS AX (PLATOON  MAXIMUM) .  The  maximum  time  a  that  can  pass 
before  a  platoon  will  update  its  ammunition  status. 

PMIN  (PLATOON  MINIMUM).  The  minimum  time  a  that  can  pass 
before  a  platoon  will  update  its  ammunition  status. 
PERMANENT  ATTRIBUTES  (INTEGER) 

PCO.CDR (PLATOON  COMPANY  COMMANDER). 

N.PCL.V. ITEMS (NUMBER  OF  PLATOON  CLASS  ?  ITEMS). 

TIME. V 

RECURSIVE  VARIABLE  IISTEGERL 
FLAG.  Yielding  argument  from  P. CLASS. 7. 

ROUTINES 

P. CLASS. V(PLATOON  CLASS  V  AMMO),  UNIFORM. F 

£gB£OHARY-llIBIggT,E_JIM£5SS8I 

C.RND.CNTR  (COMPANY  ROUND  COUNTER).  Argument  of  the  event 
UP.  COM.  AMMO  (UPDATE  COMPANY  AMMUNITION)  carrying  the 
pointer  value  of  the  company  currently  updating. 

J  -  Points  to  platoon  currently  updating. 

PROGRAM  LISTING 

1  EVENT  UP.PLT. AMMO ( J) 

2  DEFINE  J. FLAG  AS  INTEGER  VARIABLES 

3  CALL  P. CLASS. V  GIVEN  J  YIELDING  FLAG 

4  IF  FLAG  *  1, 

5  SCHEDULE  AN  UP. COM. AMMO (PCO. CDH (J) )  NON 

6  PRINT  2  LINES  WITH  TIME.V  THUS 

UP.COM. AMMO  CALLED  BECAUSE  OF  ZERO  BAL 
TIME.V  *  **.**♦• 

7  ALWAYS 

8  IF  FLAG  NE  N.  PCL.V. ITEMS  (J)  ,  "PLATOON  STILL  VIABLE 

9  SCHEDULE  AN  UP . PLT. AMMO (J) 
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10 

IN  UNIFORM. F  (PMAX.PMIN.PSTREAM)  HOURS 

1 1 

ALWAYS 

12 

RETURN 

13 

END 

EXPLANATION  OF  CODE 

Line  2 

Defines  the  recursive  variables 

used  in  the  routine. 

Lina  3 

Calls  upon  routine  P. CLASS. V  to 

update  the  platoon's 

ammo  status. 

Lines  4-7  If  the  flag  equals  1f  this  indicates  that  the 
platoon  is  at  zero  balance  for  an  ammo  type  and  the 
company  is  requested  to  update  its  ammo  status. 

Lines  8-11  If  the  flag  does  not  indicate  that  the  platoon 
has  sustained  enough  damage  to  place  it  out  of  combat, 
its  next  update  is  established. 

V.  "EVENT  8P.COM. ANNO" 

Event  OP. COM. AMMO  is  initially  scheduled  from  routine 
BASIC. LOAD  and  subsequently  randomly  reschedules  itself 
simulating  the  update  of  ammunition  assets  within  a  company. 
It  is  also  called  immediately  if  a  platoon  reaches  an  LON  of 
"1"  for  an  ammunition  type  simulating  the  initiation  of  an 
emergency  request.  Additionally,  based  on  a  returned 
argument  from  routine  COS. AMMO,  this  event  may  stop 
scheduling  updates  if  all  its  platoons  have  been  put  hors  de 
combat. 

ABS0BBNT5 
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C. END. CUTS  (COMPANY  ROUND  COUNTER).  Argument  for  event 

« 

j  A  UP .  COS.  AMMO  (UPDATE  COMPANY  AMMUNITION)  holding  a 

i 

pointer  of  a  coapany  unit. 

EVENTS  SCHEDULED 
UP. COM. AMMO 

GLOBAL  VARIABLES  (REAL) 

CMAX  (COMPA  NY  MAXIMUM).  The  aaxinun  tiae  that  can  pass  before 
a  coapany  will  update  its  aaounition  status. 

CHIN (COMPANY  MINIMUM) .  The  ainimua  tiae  that  can  pass  before 
a  coapany  will  update  its  aaaunition  status. 

CSTREAM  (COMPANY  RANDOM  NUMBER  STREAM). 

N.CCL.V. ITEMS (NUMBER  COMPANY  CLASS  V  ITEMS). 

RECURSIVE  VARIABLES  (INTEGER) 

C  -  Points  to  coapany  updating. 

SLAG.  Yielding  arguaent  of  routine  COM. AMMO. 

NO. BATTLE.  Indicates  whether  RES.REQs  should  be  filled. 

"0”  indicates  no 
"I"  indicates  yes 

COM.  AMMO  (COMPANY  AMMO)  ,  UNIFORM  .  F 
PROGRAM  LISTING 

1  EVENT  OP.COM.  AMM0{C) 

2  DEFINE  NO. BATTLE. C, FLAG  AS  INTEGER  VARIABLES 

3  LET  HO*  BATTLE  x  0 

4  CALL  COH.AHMO  GIVEN  C, NO. BATTLE  YIELDING  FLAG 

( 
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5  IF  FLAG  NE  N.  CCL .  V  .ITEMS  (C)  , 

6  SCHEDULE  A  UP . COM.  AMMC  (CJ 

7  IN  UNIFORM. F  (CMIN, CMAX,CSTREAM)  HOURS 

8  ALWAYS 

9  RETURN 
10  END 

EXPLANATION  OF  CODE 

Line  2  Defines  the  recursive  variables  used  in  the  routine. 
Lines  3-4  Set  the  indicator  flag  to  require  requisitions  to 
be  filed  and  calls  routine  COM. AMMO. 

Lines  5-8  If  the  indicator  flag  returned  indicates  that  the 
company  is  still  a  viable  combat  entity,  its  next  update 
is  scheduled. 

W.  "EVENT  B. UP. DATE" 

Event  B. UP. DATE  is  initially  scheduled  in  the  main 
program  to  initiate  a  periodic  call  for  a  battle  summary 
from  routine  UP. DATE.  This  event  subsequently  reschedules 
itself  every  24  hours. 

2SISM£NT_!TT£XgU2£ 

TIME. V 

Sa°lX££2_£AU££ 

TRUNC.P,  OP. DATE 

PROGRAM  LISTING 

1  EVENT  8. UP. DATE 

2  CALL  UP. DATE 

3  SCHEDULE  A  B.  UP.  DATE  AT  TSUNC.  F  {TIME .  V)  ♦  1 

4  HETURN 

5  END 

2I£LA£AXI£1_2£.£2££ 
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Lins  2  Calls  routine  UP. DATE  to  print  a  battle  summary 
Line  3  Schedules  another  update  in  24  hours. 


X.  "EVENT  STOP. SIMULATION" 


Event  STOP. SIMULATION  is  called  froa  the  main  program  at 
the  scheduled  time  to  stop  the  simulation.  It  causes  a 
final  printout  of  the  battle  summary  to  be  produced. 
PERMANENT  ATTRIBUTES  fBEAL) 

TIME. V 


ROUTINES  CALLED 


UP. DATE 


1  EVENT  STOP. SIMULATION 

2  LIST  TIME. V 

3  CALL  UP. DATE 

4  STOP 

5  END 

Line  2  Prints  the  time  the  simulation  ended. 

Line  3  Calls  routine  UP. DATE  to  print  a  final  battle 
summary. 


I.  "EVENT  UP. S4. AMMO" 

This  event  is  scheduled  by  event  COM. AMMO  when  a 
resupply  request  is  created.  The  purpose  of  event 
UP. S4. AMMO  is  to  process  requests  for  and  issue  ammo  froa 
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the  battalion's  reserve  stocks  of  ammunition.  In  execution, 
the  event  performs  the  following  functions:  prioritization 
of  outstanding  requests;  assessment  of  quantities  to  be 
released  to  fill  requests  subject  to  transportation 
availability;  creation  of  convoys  to  carry  the  supplies; 
creation  of  cargo  manifests  for  individual  trucks;  and  the 
dispatch  of  convoys  from  the  supply  point,  lastly,  the 
event  schedules  the  convoy  arrival  (CO.BESUPPLT. ARB)  . 

Msaaaxs 

ISSUES.  Argument  for  the  routine  containing  the  unit 
requesting  resupply. 

ISSUER.  Argument  for  the  routine  containing  the  pointer  of 
the  supply  officer  updating. 

GLOBAL  ?A8IABLBS  (INTEGER) 

SCODE (SUPPLI  CODE)  (2-d) .  HOLDS  POINTER  FOR  SCL.V.ITEM. 


CL1 .PCT (CRITICAL  L0N1  PERCENT). 

CL2.PCT  (CRITICAL  LON2  PERCENT). 

MAX. TRIP.  Maximum  travel  time  to  a  unit. 
MIN. TRIP.  Minimum  travel  time  to  a  unit. 
SCODE (SUPPLI  CODE). 


N.  SCON  TOT  (NUMBER  IN  SUPPLI  CONIOI)  . 
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! 


* 

4 


i 


N. S WANT .LIST (NUMBER  IN  SUPPLY  WANT  LIST). 

SCO. CDR  (SUPPLY  COMPANY  COMMANDER). 

PERMANENT  ATTRIBUTE  (REAL) 

TIME. V 

RECURSIVE  VARIABLES  (INTEGER). 

A  -  Holds  pointer  to  S-4  updating. 

COM.  Holds  pointer  to  coapany  updating. 

CON.  ID  (CONVOY  ID).  Holds  the  pointer  value  of  the  convoy 
currently  being  filled. 

IT. LIVES.  Indicates  if  a  convoy  has  already  been  created  to 
carry  supplies  to  a  particular  unit. 

I  -  Loop  index. 

K  -  Loop  index. 

N.RHDS  (NUMBER  OF  ROUNDS).  Holds  the  nuaber  of  rounds  being 
released  to  fill  a  reguest. 

RC. TEMP (ROUND/CUBE  TEMPORARY).  Holds  the  coaputational  value 
of  the  nuaber  of  rounds  that  aay  be  loaded  on  a  truck 
due  to  cube  restrictions. 

RNDS (ROUNDS) .  Holds  the  nuaber  of  rounds  being  released  to 
fill  a  reguest. 

RR  (RESUPPLY  REQUEST).  Holds  the  pointer  of  the  resupply 
request  being  currently  filled. 


( 
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RW. TEMP (ROUND/f EIGHT  TEMPORARY.  Holds  the  computational 
value  of  the  number  of  rounds  that  may  be  loaded  on  a 
truck  due  to  weight  restrictions. 

T.COUNT(TRUCK  COUNT).  Holds  the  value  of  the  number  of 

trucks  already  loaded  for  a  particular  resupply  reguest. 

TRKS. AVAIL  (TRUCKS. AVAILABLE)  .  Holds  the  total  number  of 
trucks  available  for  assignment  to  a  resupply  mission. 

CO (CUBE).  Holds  the  maximum  cube  that  may  be  loaded  on  a 
resupply  vehicle. 

CO. AVAIL  (CUBE  AVAILABLE).  Holds  the  total  cube  capacity  that 
is  available  within  the  supply  unit  for  the  shipment  of 
suppli es. 

CU. REQ (CUBE  REQUIRED).  Holds  the  total  cube  that  is  required 
in  order  to  ship  a  resupply  reguest. 

LON  1 .  Variable  which  indicates  whether  Level  of  Need  1 
requests  are  currently  filed  with  the  supply  officer. 

L0N2.  Variable  which  indicates  whether  Level  of  Need  2 
requests  are  currently  filed  with  the  supply  officer. 

HUL1 (MULTIPLIER  1) .  Holds  the  multiplier  for  LON  1  requests 
which  is  used  to  reduce  the  fill  on  such  requests. 

HUL2 (MULTIPLIER  2).  Holds  the  multiplier  for  LON  2  requests 
which  is  used  to  reduce  the  fill  on  such  requests. 
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MULT (MULTIPLIER) .  Holds  the  multiplier  for  both  LON  1  and 
LON  2  requests  in  the  main  part  of  the  computations. 

PCT  (PERCENTAGE)  .  Holds  the  percentage  value  of  the  amount 
released  to  fill  a  request  versus  the  total  quantity 
requested. 

RCD  (RESIDUAL  CUBE).  The  cube  remaining  in  a  CONVOY  to  be 
filled. 

RHT (RESIDUAL  HEIGHT).  The  weight  remaining  in  a  CONVOY  to  be 
filled. 

HT (HEIGHT) .  Holds  the  maximum  weight  that  may  be  loaded  on  a 
resupply  vehicle. 

HT.  AVAIL  (HEIGHT  AVAILABLE)  .  Holds  the  total  weight  capacity 
that  is  available  within  the  supply  unit  for  the 
shipment  of  supplies. 

HT.RBQ (HEIGHT  REQUIRED).  Holds  the  total  weight  that  is 
required  in  order  to  ship  a  resupply  request. 

ROUTINES  CALLED 

FILE. UPDATE  LOAD. THE. TRUCK 

NAX.F  HIN.F 

PRI. RESUPPLY  TRUNC.F 

UNIFORM .P  UP. DATE 

HT. AND. CUBE 

SS2S 
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C.CGO. LIST  (COMPANY  CARGO  LIST).  Contains  a  master  listing  of 
the  RES. REQs  that  are  loaded  on  the  trucks  belonging  to 
the  Set  ELEMENTS  (of  a  convoy)  . 

CARGO.  Contains  a  listing  of  the  T.CGO  loaded  on  a 
particular  truck. 

CWANT.  LIST  (COMPANY  WANT  LIST),  contains  a  listing  of  all 
outstanding  RES. REQs  belonging  to  a  company. 

SCONVOY  (SUPPLY  CONVOY).  Contains  a  listing  of  all  convoys 
the  supply  officer  currently  has  active. 

SNANT. LIST (SUPPLY  WANT  LIST).  A  list  of  all  outstanding 
reguests  the  supply  officer  has. 

TEMPORARY  ENTITIES 

CONVOY.  An  entity  created  to  aove  supply  trucks (TANKs)  . 
around  the  battlefield  with  supplies.  It  contains  the 
set  ELEMENTS  which  holds  the  pointers  of  the  trucks 
assigned  to  the  aission. 

RES.REQ (RESOPPLY  REQUEST). 

T.CGO (TRUCK  CARGO) .  An  entity  created  to  identify  the  cargo 
loaded  on  a  supply  truck  (TANK). 

RNOMEN (RESUPPLY  NOMENCLATURE).  Attribute  of  an  SCL.V.ITEH 
containing  the  naae  of  the  particular  aaao  type. 
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STATUS .  Transmits  information  as  to  where  a  RES. REQ  is  in 
relation  to  the  supply  system.  Values  can  be:  T0S4,  ATP, 
TOCO. 

TNOMEN (TRUCK  NOMENCLATURE).  Contains  the  name  of  a 
particular  ammo  type. 

TEMPORARY  ATTRIBUTES  (INTEGER) 

C. MV. STATE (CONVOY  MOVEMENT  STATE).  Indicates  if  a  convoy  is 

in  transit  between  supply  points. 

"0"  indicates  no 
"1"  indicates  yes. 

CO. CNVY (COMPANY  CONVOY).  Argument  of  the  routine 

CO. RESUPPLY. ARB  holding  the  pointer  of  the  convoy 
arriving. 

CONTRKS  (CONVOY  TRUCKS).  Contains  the  number  of  trucks 
assigned  to  a  convoy. 

CPNTR  (CONVOY  POINTER).  Holds  the  pointer  value  for  an  active 
CONVOY. 

L.  ELEMENTS  (LAST  ELEMENT).  System  variable  pointing  at  the 

last  truck  in  a  CONVOY'S  ELEMENTS  set. 

M. C.CGO. LIST (MEMBER  CONVOY  CARGO  LIST).  System  generated 

attribute  which  indicates  whether  a  RES. REQ  is  filed  in 
a  convoy. 
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MANIFEST.  Holds  the  pointer  of  the  CONVOY  a  RES.EEQ  is 
loaded  on. 

N.  C . CGO . LIST (NUMBER  IN  COMPANY  CARGO  LIST).  Indicates  the 
total  number  of  RES.REQs  filed  in  a  CONVOY. 

N. CARGO  (NUMBER  IN  CARGO).  Indicates  the  total  number  of 
T. CGO  items  loaded  on  a  particular  truck. 

N.T. ALLOC (NUMBER  OF  TRUCKS  ALLOCATED).  Contains  the  number 
of  trucks  to  be  allocated  to  move  the  rounds  released 
for  a  resupply  request. 

ONHAND.  Holds  the  on-hand  balance  for  rounds  of  a  particular 
ammo  type  at  the  resupply  point. 

RAC  (RESUPPLY  AMMUNITION  CODE). 

RDS.PKG  (ROUNDS  PER  PACKAGE). 

REQUESTOR.  Contains  the  pointer  to  the  unit  requesting 
resupply. 

RFILL (REQUEST  FILL).  Holds  the  number  of  rounds  released  to 
fill  a  request. 

RP (RELEASE  POINT).  Convoy  termination  point. 

RQTT (REQUIRED  QUANTITY). 

RRPNTR  (RESUPPLY  REQUEST  POINTER). 

SCREEN.  Indicates  whether  a  request  has  been  reviewed  during 
a  particular  S-4  update  cycle. 

SP (START  POINT).  Convoy  start  point. 
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SPACE.  Indicates  if  empty  space  remains  on  trucks  within  a 
CONVOY . 

SPRIORITY (SUPPLY  PRIORITY).  Indicates  the  urgency  of  need  on 
a  RES.REQ. 

TCU (TRUCK  CUBE) .  The  cube  that  a  truck  has  available  to  be 
filled. 

TPNTE (TRUCK  POINTER). 

TQTY (TRUCK  QUANTITY).  Holds  the  number  of  rounds  within  a 
T.CGO  that  are  loaded  on  a  truck. 

TRAC (TRUCK  AMMUNITION  CODE).  Of  a  T.CGO  item. 

TUT (TRUCK  WEIGHT).  The  weight  that  a  truck  has  available  to 
be  filled. 


TEMPORARY  ATTRIBUTES  (REAL) 

CU. PKG (CUBE  PACKAGE).  Of  a  standard  package  of  ammo. 
WT. PKG  (WEIGHT  PACKAGE).  Of  a  standard  package  of  ammo. 
PROGRAM  LISTING 


1  EVENT  UP.S4. AMMO (A, COM) 

2  DEFINE  R.RNDS, A,I,K, COM, RW. TEMP, RC. TEMP, ENDS, 

3  IT . LIVES,T. COUNT, N.KNDS, CON.  ID. RR, 

4  AND  TRKS. AVAIL  AS  INTEGER  VARIABLES 

5  DEFINE  MOL  1, MU L2,LON1,LON2,CU,CU. AVAIL, CU. RE  Q,  PCI , 

6  MULT, WT,WT. AVAIL. WT. REQ.RWT, BCD  AS  REAL  VARIABLES 

7  PRINT  1  LINE  WITH  TIME.V  AS  FOLLOWS 

EVENT  UP. S4. AMMO  CALLED  AT  TIME.V  *  **.**♦ 

8  " 

9  CALL  FILE.  UPDATE  (A, COM) 

10  CALL  WT. AND. CUBE  GIVEN  A 

11  YIELDING  WT. AVAIL, CU. AVAIL, TRKS. AVAIL. WT,CU 

12  * 1  TEST  IF  RESUPPLY  MISSIONS  ARE  POSSIBLE 

13  " 

14  IF  TRKS. AVAIL  *  0 

15  RETURN 

16  OTHERWISE 

17  •» 

18  CALL  PHI. RESUPPLY  GIVEN  WT. AVAIL,CU. AVAIL ,A 

19  YIELDING  MUL 1 , MUL2 ,LON 1 ,LON2 
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20 

21 

22 

23 

24 
23 
26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

K 

43 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 
0 


1 

82 

83 

84 

85 

86 
87 


•REQUEST' 

• • CHECK  RES.REQ  BY  LON,  BY  CRITICALITY,  BY  TIME 
FOR  I  -  1  TO  5,  DO 

•  i 

••ID  AND  LOOP  OVER  REC  FROM  THE  MOST  CRITICAL  UNIT 
FOR  EVERY  RES. REQ  IN  5WANT.LIST (A) 

with  spriority7res.req)=i 

AND  M.C.CGO. LIST (RES.REQ)  *  0,  DO 


t  • 


1, 


f « 


•  • 
« i 


• ‘CHECK  SCREEN 
IF  SCREEN  (RES.  REQ)  = 

CYCLE 
OTHERWISE 

LET  SCREEN  (RES.REQ)  *  1 

'•DETER  IF  THE  AMMO  IS  ON-HAND  AT  SUPPLY 
IF  ONHAND (SCODE (A, RAC (RES.  REQ) )  )  EQ  0 
CYCLE 
ALWAYS 

••  SET  MULTIPLIERS 

LET  MULT  =  1.0 

IF  SPSIOSITY  (RES.REQ)  *  1, 

LET  MULT  =  MUL 1 
ALWAYS 

IF  SPRIORITY (RES.REQ)  =  2, 

LET  MULT  *  MUL2 
ALWAYS 


POINT 


DETER  IF  THERE 
LET  N.RNDS  *  R 
LET  R.RNDS  =  R 
IF  N.RNDS  GT  0 
LET  N.RNDS  * 
ALWAYS 


IS  ENOUGH 
3TY  ( RES.  RE( 
JTYiRES.REC 
(HAN D  (SCODJ 


AMMO  TO  MEET 
!)  *  MULT 

V,  RAC  (RES.  RE 


REQMNTS 


ONHAND (SCODE (A, RAC (RES 


mi 


n 


"DETERMINE  THE  WT  AND  CUBE  TO  BE  SHIPPED 
LET  NT.  REQSN.  ENDS*  WT. PKG (SCODE (A , RAC (RES.  RE< 
/RDS. PKG (SCODE (A, RAC  (RES.REQ) ) 
LET  CU.REQa  H. HNDS*CU. PKG (SCODE (A,RAC  (RES. R 
/RDS. PKG (SCODE (A, RAC  (RES.REQ) ) ) 

"  DETER  IF  A  UNIT  CONVOY  IS  ALREADY  FORMED 
FOR  EVERY  CONVOY  IN  SCONVOY(A) 

WITH  C.  MV .  STATE  (CONVOY)  »  0  AND  SP(CONVOY)  * 

DO 

CONVOY 


AND  RP 

•  »CA 

LET  CON. ID  *  CONVOY 
LET  IT. LIVES  »  1 


.MV.  STATE  (CONVOY)  -  0  AND  SP(C 
(CON  VO  if  »  REQUESTOR  (RES.REQ)  , 
PTURE  THE  POINTER  VALUE  OF  THE 


• 'CHECK  IF  SPACE 
IF  SPACE  (CONVOY), 
IF  WT.HEQ  “ 

OB  “ 

LET 


ON  CONVOY  TRUCKS 


GT 


IS  AVAIL 
.  *  1 

TWTJL.  ELEMENTS  (CONVOY)) 

CU.BEQ  GT  TCUJL. ELEMENTS (CONVOY) ) 

RWT  *  TWT(L. ELEMENTS (CONVOY)) 

BCD  »  TCUlL.  ELEMENTS  (CONVOY)) 
RW.TENPaRWT 

/WT. PKG (SCODE (A, RAC  (RES . REQ) ) ) 
RDS. PKG (SCODE (A, RAC (RES.REQ) ) ) 
*  ECU 

/CU. PKG (SCODE 
RDS. PKG (SCODE i 
MIN.F (RW. TEMP, 


LET 

LET 


LET  RC.TEMP 


BHDS 
SPACE  (CONVOY)' 


LET 
LET 
ELSE 

LET  BROS  a  N.RNDS 
ALWAYS 


0 


>E(A, 

ifk: 


A, RAC  (RES.REQ) ) ) 
*  RAC (RES . REQ) ) ) 
TEMP) 
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IF  ENDS  le  0# 
go  to  endfill 
otnerwi.se 

CHEATS  A  T.CGO 

LET  TPNTB(T.CGO)  *  L.  ELEMENTS  (CONVOY) 

LET  RRPNTE (T.CGO)  =  BES.BEQ 

LET  TNOMEN  (T.CGO)  =  BNOMEN  (RES . BEQ) 

LET  TBAC(T.-:GO>  *  BAC  (BES.  BEQ) 

LET  TQTY  (T.CGO)  =  BEDS 

FILE  T.CGO  IN  CARGO  (L.  ELEMENTS  (CON VOY) ) 

"REDUCE  THE  QUANTITY  ON  THE  BES.BEQ 


LET  N. RNDS  *  N.RNDS  -  BNDS 
LET  RFILL (BES.BEQ)  =  BFILL  (RES . BEQ)  ♦  BNDS 
LET  BQTY  (BES.BEQ)  =  BQTY  (BES.BEQ)  -  ENDS 
••REDUCE  THE  ON-HAND  BALANCE  OF  STOCKS 


••REDUCE  THE  ON-HAND  BALANCE  OF  STOCKS 
LET  ONHAND  (SCODE (A.BAC  (BES.BEQ) ))  * 

ONHAND  (SCODE (A  , RAC  (BES . BEQ)  ) ) -BNDS 
••REDUCE  THE  HEIGHT  AND  CUBE  FOB  THE  BEQ 
LET  NT. BEQ*  Tfi UNC. F (HT . BEQ  -  BN~ 


. BEQ*  TBUNC.F(HT.BEQ  -  BNDS 

*WT. PKG (SCODE (A.BAC  (RES . BEQ) ) ) 
/RDS.PKG (SCODE (A, RAC  (BES.  BEQ)  )  ) ) 
LET  CU.BEQ®  TBUNC.  F  (CU  .BEQ  -  BNDS 

*CU.  PKG  (SCODE  (A.BAC  (BBS.  BEQ)  ) ) 
/RDS.PKG (SCODE (A.BAC (BES.BEQ)) ) ) 
••REDUCE  THE  HT  AND  CUBE  AVAIL  ON  THE 
TRUCK 

LET  THT  (L.  ELEMENTS  (CONVOY))  * 

TBUNC.  F  (THT  (E.  ELEMENTS  (CONVOY) ) 

-  BHDS*HT.  PKG  (SCODE  (A.BAC  (BES.BEQ)  ) 
✓RDS.PKG  (SCODE  (A.HAC  (BES.  BEQ) )  ff 

LET  1CU  (L. ELEMENTS  (CONVOY)  )  = 

TBUNC.  F  (TCB  (L.  ELEMENTS  (CONVOY) ) ) 

-  BNDS*HT.PKG 'SCODE  (A.BAC  (RES.  BEQ)  ) 
/EDS. PKG  (SCODE  (A,BAC  (BES.BEQ)  ) )) 

ALHAY S 

••FILL  IN  CONVOY  MANIFEST 
IF  CON. ID  IS  NOT  IN  SOME  SCONVOY 
FILE  CON. ID  IN  SCONVOY  (A) 

ALHAYS 

IF  BES.BEQ  NOT  IN  C.CGO.LIST, 

FILE  BES.BEQ  IN  C.CGO. LIST (CON . ID) 

ALHAYS 

LET  MANIFEST  (BES. BEQ)  *  CON. ID 
LET  STATUS (BES.BEQ)  *  "TOCOMiANY" 

IF  BQTY (BES. BEQ)  »  0 
GO  TO  BEQUESTLOOP 
OTHER  HISS 
ALHAYS 

•END. SPACE. CHECK'  LOOP 
•BALLY' 

••CHECK  NUMBSB  OF  TBUCKS  AVAIL  FOB  SHIPMENT 
IF  TBKS. AVAIL  EQ  0 
GO  TO  FINALCHECK 
OTHBRHISE 

••IF  A  CONVOY  DOESN'T  EXIST  CREATE  ONE 
IF  IT. LIVES  EQ  0 
CREATE  AN  CONVOY 
LET  CPNTB (CONVOY)  »  CONVOY 
LET  COB. ID  *  CONVOY 
LET  BP  (CONVOY)  «  REQUESTOB  (BES .  BEQ) 

LET  SP  (CONVOY)  ■  A 
ALHAYS 

"DETERMINE  THE  *  OF  TBKS  ABE  ON-HAND 


BEQ  IN  C.CGO.LIST  (CON. ID) 


*  CON. ID 
"TOCOMiANY" 
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152 

153 
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155 
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158 
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168 

169 
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171 

172 

173 

174 

175 

176 

177 

178 

179 

180 
181 
182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 

193 

194 

195 

196 

197 

198 

199 

200 
201 
202 

203 

204 

205 

206 

m 

209 

210 


•  i 


« « 


•  • 


« « 


•  t 


' •  IF  NOT  ADJUST 

IF  WT.BEQ  LT  WT. AT  AIL  AND  CU.BEQ  IT  CU. AVAIL, 

1ST  N .  X .  ALLOC  |  BES .  BED)  = 

TEONC.  F  (M  AX  .  F  (WT .  BEQ/WT,C0 ,  REQ/CU)  + 1) 

ELSE 

LET  N.T.  ALLOC  {BES.EEQJ  *  TfiKS. AVAIL 
ALWAYS 

LET  TRKS. AVAIL  *  TBKS.  AVAIL-N.T.  ALLOC  (BES  .  BEQ) 

•'FILL  IN  CONVOY  MANIFEST 
IF  CON. ID  IS  NOT  IN  SOME  SCONVOI 
FILE  CON. ID  IN  SCONVOY(A) 

ALWAYS 

IF  BES.BEQ  NOT  IN  C.CGO.LIST. 

LET  STATUS (BES.BEQ)  ®  “TOCOMPANY" 

FILE  BES.BEQ  IN  C . CGQ .LIST  {CON . ID) 

ALWAYS 

LET  MANIFEST (BES.BEQ)  *  CON. ID 

ADD  N.T.ALIOd  (BES.BEQ)  TO  CONTBKS  (CON. ID) 

LET  BB  *  BES.BEQ 
CALL  LOAD.  THE.  TRUCKS 

(A,HH, WT.BEQ,CU.R£Q,N.BNDS,CON.ID) 

••  ADJUST  THE  WT. AND  CUBE  AVAIL  FOB  SHIPPING 
CALL  WT. AND. CUBE  GIVEN  A 

YIELDING  WT. AVAIL, CU. A VAIL, TBKS. AVAIL, WT,CU 

•REQUESTLOOP* 

"UPDATE  SWANT. LIST  FILES 

.  GT  C.  LI  PCI) 

X($PRZOBITI  (BES.SEQr  *  2  AND  PCT  GT  C.L2PCT ) 
BEHOVE  BES.BEQ  FROM  SWANT.  LIST  (A) 

ELSE 

BEHOVE  BES.BEQ  FROM  SWANT . LIST (A) 

ALWAYS 

LET  IT. LIVES  *  0 


LOOP 

LOOP 
T  • 

•  *  DISPATCH  ALL  CONVOYS  CREATED 
POR  EVEBY  CONVOY  IN  SCONVOI(A) 

WITH  C.  MV.  STATE  (CONVOY)  *0  AND  SP  (CONVOY)  =A,  DO 
LET  C  .  MV . STATE  (CONVOY)  *  1 
LOOP 
* « 

IF  CON. ID  HE  0. 

SCHEDULE  A  CO. RESUPPLY. ABB (CON .ID) 

IN  UNIFORM. F(flINTBIP,MAXTRIP,TSrBEAH)  MINUTES 
ALWAYS 

#  i 

"BESET  LOOP  CHECKS 

FOB  ALL  RES. REQ  IN  CWANT .LIST (SCO. CDS  (A) ) ,  DO 
LET  SCREEN (BES.BEQ)  *  0 
LOOP 
RETURN 
END 

EXPLANATION.  OP  CODE 


Lines  2-6  Define  recursive  variables  for  the  routine. 


Line  7  Prints  a  aessage  narking  the  beginning  of  the  event. 
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Line  9  Calls  routine  FILE. UPDATE  which  files  new  requests 
and  checks  old  requests  for  duplication. 

Lines  10-11  Calls  routine  HEIGHT. AND. CUBE  to  assess  the 
total  weight  and  cube  capacity  available  to  handle 
shipments  of  supplies  forward. 

Lines  13-16  Check  if  all  resupply  vehicles  are  already  in 
use.  If  so,  the  routine  is  ended  with  no  further  action 
taken. 

Line  18-19  Calls  routine  PBI.BESOPPLX  to  determine  if  LON1 
and  LON2  requests  should  be  aodified  in  order  no  fill 
■ore  requests  with  a  lesser  amount  of  aaao. 

Lines  21-23  Start  the  major  loop  of  the  routine.  Initialize 
an  index  to  the  most  urgent  LOH  a  resupply  request  can 
have  and  begin  the  loop  which  will  fill  requests.  Loop 
ends  on  line  192. 

Lines  25-28  Start  an  inner  loop  of  the  routine  to  identify 
the  aost  critical  resupply  request  on-hand  to  fill 
first.  Loop  ends  on  line  191. 

Lines  30-34  Check  the  screen  attribute  of  a  resupply 

request  to  deteraine  if  the  request  has  been  reviewed 
before  in  the  current  cycle.  If  the  request  has  been 
reviewed,  the  request  is  cycled. 
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<  Linas  36-39  check  the  availability  of  the  aaao  requested  at 

^  the  supply  point.  If  none  is  available  the  request  is 

cycled. 

Lines  41-48  Set  aultipliers  for  high  priority  requests  as 
appropriate.  The  purpose  of  the  aultipliers  is  to 
reduce  the  fill  on  high  priority  requests  in  order  to 
release  truck  space  to  fill  sore  high  priority  requests. 

Lines  50-55  Deteraine  if  there  is  enough  aaao  available  to 
fill  requests.  If  not,  the  request  is  filled  with  what 
is  available. 

Lines  57-61  Deteraine  the  weight  and  cube  needed  to  ship 
the  number  of  rounds  requested. 

Linas  63-66  Start  an  inner  loop  which  checks  to  see  if  a 
convoy  is  already  formed  for  requestor  of  the  current 
request.  If  one  exists,  this  loop  is  entered  and  any 
available  space  on  trucks  already  committed  to  the 
convoy  is  filled  before  more  trucks  are  committed.  Loop 
ends  on  line  134. 

Line  68  Captures  the  pointer  value  of  the  convoy  formed. 

Line  69  Initializes  a  variable  signifying  that  a  convoy  is 
already  formed  for  the  unit. 
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Lines  72-128  Perform  an  IF  check  to  determine  if  space  is 
still  available  on  convoy  trucks.  If  so,  the  logic 
embedded  to  line  133  is  executed;  if  not,  control  is 
transferred  to  line  133. 

Lines  73-87  Perform  an  IF  check  to  compute  the  number  of 
rounds  that  may  be  shipped  on  the  convoy  subject  to  the 
available  weight  and  cube.  Satisfying  the  IF  condition 
indicates  that  the  current  request  will  fill  the  room 
available.  Transfer  to  the  ELSE  condition  indicates  that 
the  request  will  leave  space  on  trucks  for  additional 
requests. 

Line  75  Computes  the  residual  weight  available  on  the 
convoy. 

Line  76  Computes  the  residual  cube  available  on  the  convoy. 

Lines  77-79  Compute  the  rounds  that  may  be  shipped  for  a 
request  subject  to  the  weight  limitations  of  the  truck. 

Lines  80-82  Compute  the  rounds  that  may  be  shipped  for  the 
request  subject  tc  the  cube  limitations  of  the  truck. 

Line  83  Specifies  the  number  of  rounds  to  be  released 
subject  to  the  minimum  restriction. 

Line  84  Sets  the  space  attribute  of  the  convoy  to  indicate 
that  there  is  no  space  available. 


251 


Lines  85-86  Mark  the  ELSE  logic  which  indicates  that  the 
request  may  be  filled  with  room  to  spare. 

Line  37  Marks  the  end  of  the  weight  and  cube  loop. 

Lines  89-121  Perform  an  IF  check  to  see  if  rounds  are  to  be 
loaded  on  committed  convoy  trucks.  If  BNDS  is  greater 
than  zero,  the  logic  to  load  the  truck  is  executed.  If 
not,  control  is  passed  to  line  133. 

Line  92  Creates  a  T.CGO  to  hold  information  as  to  the  type 
and  quantity  of  ammo  to  be  loaded  on  a  truck. 

Line  93  Captures  the  pointer  value  of  the  truck  the  cargo 
is  loaded  on. 

Line  94  Captures  the  pointer  value  of  the  resupply  request 
being  filled. 

Line  95  Captures  the  nomenclature  of  the  reguest  being 
filled. 

Line  96  Captures  the  ammunition  code  of  the  request  being 
filled. 

Line  97  Captures  the  guantity  being  loaded  on  the  truck. 

Line  98  Files  the  cargo  on  the  last  truck  in  the  convoy. 

Lines  99-100  Reduce  the  number  of  rounds  yet  to  be  filled 
for  the  request. 
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Line  101  Adds  the  quantity  released  to  the  fill  attribute 
of  the  request. 

Line  102  Reduces  the  required  quantity  for  the  resupply 
request. 

Lines  103-105  Reduce  the  on-hand  stocks  for  the  anao  type 
at  the  supply  point. 

Lines  106-111  Reduce  the  weight  and  cube  required  to  fill 
the  request. 

Lines  113-120  Reduce  the  weight  and  cube  available  on  the 
truck  to  fill  requests. 

Line  121  Closes  out  the  inner  IF  check. 

Lines  121-132  Fill  in  the  convoy  aanifest. 

Lines  125-127  check  if  the  existing  convoy  is  in  the  set  of 
convoys  owned  by  the  supply  officer.  If  not,  the  convoy 
is  filed. 

Line  128  Points  the  resupply  request  to  the  convoy  it  is 
loaded  on. 

Line  129  Insures  that  the  status  of  the  convoy  shows  it 

enroute  to  the  supported  unit. 

» 

Lines  130-132  Check  to  see  if  the  request  has  been  filled. 
If  so  the  loop  is  cycled  to  the  next  request.  If  not, 
logic  continues  to  see  if  it  can  be  loaded  on  an 
additional  truck  for  the  convoy. 
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Lines  1 36- 140  Determine  if  there  are  tracks  available  for 


assignment  to  the  convoy.  If  not,  all  loops  are 
terminated. 

Lines  142-149  Hake  a  check  to  determine  if  a  convoy  is 
already  formed  to  ship  supplies  to  the  unit.  If  not  a 
convey  is  formed,  and  attributes  are  set  capturing  its 
pointer  value,  start  point,  release  point  (end  point), 
and  setting  a  variable  equal  to  its  pointer  value  for 
later  computations. 

Lines  151-159  Determine  if  the  necessary  number  of  trucks 
are  available  to  ship  the  supplies.  If  not,  the  number 
of  trucks  that  are  available  are  assigned  to  the 
mission. 

Lines  161-173  Pill  in  the  convoy  manifest. 

Lines  162-164  Check  if  the  existing  convoy  is  in  the  set  of 
convoys  owned  by  the  supply  officer.  If  not,  the  convoy 
is  filed. 

Lines  165-166  Check  if  the  resupply  request  is  filed  in  the 
convoy  manifest.  If  not,  the  convoy  is  filed  and  the 
status  changed  to  show  enroute  to  the  supported  unit. 

Line  169  Points  the  resupply  request  to  the  convoy  it  is 
loaded  on. 
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Line  170  Adds  -the  nuaber  of  trucks  allocated  to  the 


convoy*s  total. 

Lines  171-172  Capture  the  resupply  pointer  and  transfer 
control  to  a  routine  which  loads  the  request  on  the 
trucks. 

Lines  175-177  Call  routine  HEIGHT . AND. CUBE  again  to  update 
the  weight  and  cube  now  available  on  trucks  at  the 
battalion  trains  for  shipping. 

Lines  179-187  Update  S-4  request  files  dropping  those  LON  1 
and  LON  2  files  that  have  been  filed  past  a  critical 
ainiaua  and  dropping  all  other  requests  that  have  at 
least  a  partial  fill. 

Line  189  Resets  the  IT. LIVES  variable  to  zero. 

Line  191  closes  out  the  inner  loop  started  on  line  25 

carrying  with  it  the  most  critical  request.  Transfers 
control  back  to  acquire  the  next  request  or  out  to  the 
next  LON  value. 

Line  192  Closes  out  the  aajor  loop  started  on  line  21. 
Transfers  control  back  to  change  the  LON  value  being 
considered  to  the  next  value  or  out. 

Lines  194-198  Change  the  aoveaent  state  of  all  convoys 
created  in  ordar  to  dispatch  the  convoys. 


mw.ium 
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Lines  200-203  Deteraine  if  convoys  have  been  foraed  this 
iteration  of  the  routine.  If  so,  a  company  resupply 
arrival  tiae  is  scheduled. 

Lines  205-208  Reset  the  screen  attribute  on  still  viable 
requests  for  the  next  iteration  of  the  loop. 


Z.  "EVENT  FIREKILL" 

This  event  is  scheduled  by  event  UP. H. AMMO  if  a  weapon 
system  sustains  a  firepower  hill.  The  purpose  of  the  event 
is  to  redistribute  the  weapon  system's  on-board  ammo  to  the 
other  aembers  of  its  platoon.  In  execution,  each  of  the  six 
ammo  types  a  weapon  could  carry  are  reaoved  from  the  weapon 
and  distributed  to  the  other  undamaged  weapons  in  the 
platoon  in  accordance  with  each  weapon's  urgency  of  need  for 
that  ammo  type. 

ARGO BEST 

VICTIM .  Points  to  the  weapon  system  that  has  been  hilled. 

2SmS_I2_fl5Al! 

AflHOI .  AP . TOM (ARBOR  PIERCING/TOW  ROUNDS ) . 

ARB02.  HE. DRAG (HEAT/DRAGON  ROUNDS) . 

ABB03.  AVI  .OR .  HSL3  (ALTERNATE  WEAPON  1  OR  MISSILE  3). 

AMH04.  AW2. OR. ADM (ALTERNATE  WEAPON  2  OR  AIR  DEFENSE 


MISSILE) 


PCODE  (PLATOON  CODE)  (2-d)  .  Holds  the  pointer  value  for  a 


platoon’s  PCL.V.IIEMs  (PLATOON  CLASS  V  ITEMS). 


A  -  Points  to  the  weapon  killed. 

AC.  Holds  the  value  of  the  aaao  code  being  reviewed. 
DEL.  Placeholder  for  aaaunition  types  being  delivered. 

I  -  Loop  index. 

NO. BATTLE.  Indicates  whether  RES.REQs  should  be  filled. 

"0"  indicates  no 
M1W  indicates  yes 
PL.  Points  to  a  PLATOON. LEADER. 

TK.  Points  to  a  TANK. 


HOCL££NES_CALL£D 
OP. DATE,  H.AMHO,  P. CLASS. V 
SETS  OS ED 

PLAT. ONIT(PLATOON  ONIT) .  Owned  by  a  platoon. leader.  Meabers 
are  the  unit's  coabat  vehicles (TANKS) . 

TEMPORARY  ATTRIBUTES  (INTEG^g) 

AMR05 (AMMO NITION  5).  Of  TANK. 

AHR06 (AMMUNITION  6).  Of  TANK. 

AP.TON (ARMOR- PIERCING/TON) .  Aaaunition  1  of  TANK. 

AR1 .03 . MSL 3 (ALTERNATE  WEAPON  1  OB  MISSILE  3).  Aaaunition  3. 
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AW2. OS. ADM  (ALTERNATE  WEAPON  2  OH  AIB  DEFENSE  MISSILE). 
Ammunition  4. 

HE. DRAG (HEAT/DRAGON  ROUNDS) .  Ammunition  2  of  TANK. 

FKILL  (FIREPOWER  KILL) . 

FLAG.  Yielding  argument  of  routine  W.AMMO;  not  used. 

KKILL  (CATASTROPHIC  KILL). 

MFKILL  (MOBILITY  AND  FIREPOWER  KILL). 

MKILL (MOBILITY  KILL). 

OH1 (ON-HAND  1).  Current  balance  of  aaaunition  1  on  a  TANK. 

OH2  (ON-HAND  2).  Current  balance  of  aaaunition  2  on  a  TANK. 

OH3 (ON-H AND  3).  Current  balance  of  aaaunition  3  on  a  TANK. 

OH4 (ON-HAND  4).  Current  balance  of  aaaunition  4  on  a  TANK. 

OHS (ON-HAND  5).  Current  balance  of  aaaunition  5  on  a  TANK. 

OH6 (ON-HAND  6).  Current  balance  of  aaaunition  6  on  a  TANK. 

P. SHORT  (PLATOON  SHORTAGE).  Current  shortage  of  a  PCL.v.iTEM 
(PLATOON  CLASS  V  ITEM)  .  Unique  to  each  platoon  and  ammo 
type. 

PLTLDR (PLATOON  LEADER)  . 

SL0AD1  (STOWED  LOAD  1).  Optimal  load  aaao  type  1. 

SLOAD2 (STOWED  LOAD  2) .  Optimal  load  aaao  type  2. 

SL0AD3  (STOWED  LOAD  3)  .  Optimal  load  aaao  type  3. 

SLOA04  (STOWED  LOAD  4).  Optiaal  load  aaao  type  4. 

SLOAD5 (STOWED  LOAD  5).  Optiaal  load  aaao  type  5. 
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SL0AD6  (STOWED  LOAD  6) .  Optimal  load  ammo  type  6. 
SYS.  TYPE  (SYSTEM  TYPE). 

TAC 1 . ( TANK  AMMUNITION  CODE  1). 

TAC2. (TANK  AMMUNITION  CODE  2). 

TAC3. (TANK  AMMUNITION  CODE  3) . 

TAC4 . (TANK  AMMUNITION  CODE  4). 

TAC5. (TANK  AMMUNITION  CODE  5). 

TAC6. (TANK  AMMUNITION  CODE  6). 


TEMPORARY  ENTITIES 


TANK 


EVENT  FIREKILL  (A) 

DEFINE  NO. BATTLE, FLAG, TK,PL, DEL, AC, A, I 
AS  INTEGER  VARIABLES 

i  i 

PRINT  1  LINE  THUS 
t EVENT  FIREPOWER  KILL  CALLED 

*  *  CHANGE  KILL  STATUS  TO  ELIMINATE  THE  WEAPON 
FROM  FURTHER  UPDATES 

LET  MKILL(A)  ■  1 

•  • 

FOR  I  *  1  TO  6,  DO 

i i SET  UP  ARTIFICIAL  DELIVERY 
1 1 

GO  TO  1,2, 3, 4, 5, 6  PER  I 

LET  DEL  =*  AMMO  1(A) 

LET  AC  *  TAC  1(A) 

•  2» 

LET  DEL  -  AMMO 2  (A) 

LET  AC  ■  TAC2  (A) 

1 3 1 

LET  DEL  *  AMM03  (A) 

LET  AC  *  TAC3  (A) 


'4* 

LET  DEL 


LET  DEL 
LET  AC  » 
•  6* 

LET  DEL 

LET  AC  3 
1 1 


=  AMR04  (A) 
TAC4  (A) 

*  AMH05  (A) 
TAC5  ( A) 

|  AMH06  (A) 
TAC6 (A) 
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35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

H 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 
35 
86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 


•  t 


1  'PILL  AS 

FOR  EVERY  A  IN  PLAT. UNIT (PLTLDfi)  ,  DO 

IF  MKILL  ( A)  =  1  OR  HFKILL  (A)  =  1  OR  FKILL(A)=1 
OR  KKILL  ( A)  =  1 
CYCLE 
OTHERWISE 


1 1 


i  • 


i » 


• « 


i « 


IF  TAC1jA)=AC 
LET  OH  l 


(A)  =OH  1  ( A)  +  DEL<  (SLOAD1  (A)-OHl  (A)  ) )  / 
P. SHORTjPCODE (PLTLDfi, AC) ) 


LET  AH HOI  (A) - AHH01 


GO  TO  TKLOO? 
OTHERWISE 

IF  TAC2 (A) ®AC 
LET  OH2 ( 


HH01 (A) ♦DEL 

(SLOADl  (A)  -AHH01  (A)  )  ) 

P . SHORT (PCODE (PLTLDfi , 


ic) ) 


(A)  *OH2  (A)  *DEL<  (SLO  AD2  ( A) -OH2  (A)  )  )  / 
P. SHORT jPCODE (PLTLDfi, AC)) 
LET  AHM02  (A)  =AHH02  (A)  ♦DEL 

<  (SLOAD2  (A) -AHH02  (A)))  / 

P.  SHORT  (PCODE  (PLTLDfi,  AC) ) 

GO  TO  TKLOOP 
OTHERWISE 


IF  TAC3 
LET 


Oth  (A)  =OH3  (A)  ♦DEL*  (SLOAD3  ( A) -OH3  (A)  )  )/ 
P. SHORT (PCODE (PLTLDfi, AC)  ) 
- ...  - --  ^+DE' 

P  .SHORT  (^CODE  (PLTlDl 


LET  AHH03  (A)  =  AHH03  (A) +DEL 

GO  TO  TKLOOP 
OTHERWISE 


) 


IF  TAC4  (A)  *AC 

LET  0H4  (A)  *OH4  (A)  +DEL<  (SLOAD4 ( A) -0H4  (A) ) )  / 
P.SHOfiTjPCODE (PLTLDfi, AC)) 
LET  AHH04  (A)  *AHH04  (A)  +OBL 

<  (SL0AD4  (A)  -AHH04  (A) )  )  / 

P .  SHORT  (PCODE  (PLT  LDfi,  AC) ) 

GO  TO  TKLOOP 
OTHERWISE 


IF  TAC5 (A) 
LET  OH5i 


AC 

(A)  »OH5  (A)  +DEL<  (SLO AD5  (A) -OH5  (A)  ) 
P. SHORT JPCODE (PLTLDfi, AC) ) 
LET  AHH05(A)  =AHH05JA)>DEL 

<  (SLOAD5  (A) -AHH05  (A)  )/ 

P. SHOfiT (PCODE  (PLTLDfi , AC) 

GO  TO  TKLOOP 
OTHERWISE 


)/ 


) 


IF 


ItCOi(6\a)A*OH6  (A)  ♦  DEL<  (SLO  AD6  J  A^OH6 


LET 

LET  AHH06  ( A) 


P. SHOfiT (PCODE (PLTLDfi, Icj j 
AHH06  (A)  +DEL 
<  SL0AD6  (A) -AHH06  (A)  )  / 

P. SHORT (PCODE (PLTLDfi, 


)/ 


ALWAIS 
•TKLOOP*  LOOP 
LOOP 

FOR  EVERY  TK  IN  PLAT .UNIT(PLTLDB  (A)  )  ,  DO 
IF  SIS. TIPS  (TK)  EQ  7, 

CYCLE 
OTHERWISE 
LET  NO. BATTLE  *  1 

CALL  W. AHHO  (TK, NO. BATTLE)  YIELD! kG  FLAG 
LOOP 
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AC)) 


& 


awrc-*. 


103  •  • 

104  CALL  P.  CLASS.  V  (PLTLDR(A)  ) 

105  RE TORN 

106  END 

EXPLANATION  OF  CODE 

Line  2-3  Define  recursive  variables  used  in  the  routine. 

Line  5  Prints  a  message  indicating  that  the  routine  has 
been  called. 

Lines  7-9  Change  the  kill  status  of  the  weapon  system  to 
eliminate  it  from  further  supply  computations. 

Line  12  Begins  the  major  loop  for  tha  routine,  looping  over 
the  six  ammo  types  carried  on  a  weapon  and  distributing 
these  assets  to  the  other  members  of  the  platoon.  Loop 
ends  on  line  95. 

Lines  16-33  Set  DEL  egual  to  the  amount  being  taken  from 
the  damaged  weapon  and  AC  egual  to  its  identifying  ammo 
code. 

Lines  36  Begins  an  inner  loop  over  the  undamaged  weapons  of 
the  platoon  in  order  to  distribute  tL<?  damaged  vehicles 
ammo.  Loop  ends  on  line  95. 

Lines  37-40  Check  the  weapon  being  considered  for  any 
damage  and  cycles  if  damage  is  determined. 

Lines  43-93  Loop  over  the  six  ammo  types  carried  by  the 
undamaged  weapon  to  see  if  it  carries  the  ammo  being 
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distributed  froa  the  damaged  vehicle.  If  a  natch  is 
Bade,  the  amount  delivered  is  equal  to  the  amount  being 
taken  from  the  damaged  vehicle  times  the  ratio  of  the 
weapon’s  need  to  the  platoon’s  overall  need. 

Line  94  Closes  the  weapon  systea  loop  begun  on  line  36. 
Control  is  transferred  either  to  the  next  weapon  or  to 
the  next  aaao. 

Line  95  Closes  the  ammo  loop  begun  on  line  12.  Control  is 
transferred  either  to  the  next  aaao  type  or  out. 

Lines  96-102  Cause  every  weapon  system  to  update  its  ammo 
status. 

Line  104  Causes  the  platoon  to  update  its  ammo  status. 
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